Monday, October 15, 2018

The Case for WebForms in a .NET Core world


I wanted to be able to write a great article on the power of WebForms. Of how they are just easier to use and more stable than MVC or RAZOR.  

I'm not going to lie, I love WebForms, and I've made WebForms dance to my tune for 15 years now. The typical complaints regarding lack of control of the rendered HTML or CSS, I've ignored and basically forced it to perform how I wanted. I understand WebForms. They work like WinForms in a context that to me makes sense. 

So, yes, I wanted to be able to write a great article on why we need them, why we should keep them, and other such things. 

And instead, while doing my research, and hunting for various numbers, I ran across a reference to SharePoint.

The reference in question was discussing a comparison between SharePoint, WebForms and the then just released MVC Framework, and held specific notations how WebForms had more structure than MVC but had none of the "out-of-the-box" functionality of SharePoint. The stance of the author (which I'm still not sure I agree with) was that WebForms had the drawbacks of both, with none of their features.  Like I said, I can't quite agree to that, but the article was enough to get me thinking. 

I mean, I remember SharePoint when it was first released. When it could be used to build websites. Or Intranets. Or whatever someone twisted it to do. 

The thing is, is that it has been years since I last saw a SharePoint install. None of my clients use it, the Network Architects for my company don't spec it, and it's not something I ever think about considering as an option for  my clients. SharePoint is a powerful tool, it integrates with basically every aspect of Office and Windows to produce a data integration tool for Enterprise. I'm not arguing that.  I'm stating that I haven't seen it in years, don't ever think about it, and have a general negative impression of it due to the complexity it invoked when I did last attempt to do something with it years ago. 

Just like MVC. 

When MVC first released, I poked at it a bit, then went back to work building things with WebForms. I didn't like it. It didn't behave the way I wanted to interact with an ASP.Net site. It was C#. And it had so may files to create any given page.  

I never really gave it a fair shot, because in the end building WebForms with VB.Net was faster. I was able to generate an application from design to production at speed and with ease. Which is typically a highly important aspect to things. After all, the three staples of software development are always cost, time and quality. Using WebForms, I was able to impact all three aspects positively and do so consistently.  

Which is the big case for WebForms. If you know what you're doing, working with them is fast; getting an application up and running is trivial. In my opinion, even getting the CSS to behave as expected is easy. 

And that's something meaningful.  Especially as a consultant, building software to solve other people's problems on their dime. 



Monday, October 8, 2018

Learning Ember -- Integrating Bootstrap

This is my continuing efforts to work with the Ember JS (www.emberjs.org) Framework. The expectation is to build a simple wish list of items.  Part one started the Ember application, part two started our first route, part three added a Click Event to the code while part four introduced components for code reuse. Today's section works on integrating Bootstrap into the framework. 
There is an Ember CLI element that does some of this work for you, but I just worked with integrating the artifacts from the Bootstrap website directly into my project.

To start with, I just worked with the CDN version of Bootstrap (https://getbootstrap.com) as I wanted to get it working before I worried about having downloaded artifacts. So, I first went to the getting started page for Bootstrap which provides the necessary links for CDN.

Then I opened up the index.html file to add the CDN references there, placing them between the content-for components for the "head" and "head-footer" in the HEAD section of this file.
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>EmberLearn</title>
    <meta name="description" content="">
    <meta name="viewport" content="width=device-width, initial-scale=1">

    {{content-for "head"}}

    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"; integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous">
    

    <script src="https://code.jquery.com/jquery-3.2.1.slim.min.js"; integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN" crossorigin="anonymous"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js"; integrity="sha384-ApNbgh9B+Y1QKtv3Rn7W3mgPxhU9K/ScQsAP7hUibX39j7fakFPskvXusvfa0b4Q" crossorigin="anonymous"></script>
    <script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js"; integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl" crossorigin="anonymous"></script>
    {{content-for "head-footer"}}

  </head>

This means that the pages will include the Bootstrap elements as they're served. Now, my initial thought was that I'd be able to add the "container" DIV to this file, wrapping it around the content-for component for the body and body-footer. This didn't work. The EMBER content was served outside of the container DIV.

Instead, you need to open up the application.hbs, which is the global template for the Ember content, and add the container DIV here.
1
2
3
4
5
<div class="container">
    <h1>Wish List</h1>

    {{outlet}}
</div>

Elements like the NAVBAR could be implemented in either the index.html or application.hbs files.

But, this isn't the end of things. We now need to style our item-list component to display its content within the context of Bootstrap elements.

So, we open up the item-list component template file, and wrap the H2 element, and the UL elements within row DIVs and column DIVS
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
<div class="row">
    <div class="col-12">
        <h2>{{title}}</h2>
    </div>
</div>
<div class='row'>
    <div class="col-12">
        <ul>
            {{#each items as |item|}}
            <li {{action "showItem" item}}><cite>{{item}}</cite></li>
            {{/each}}
        </ul>
    </div>
</div>

This is a step in the right direction, but we also want the items to be displayed in a slightly better context as well. So, we'll switch the LI out for a DIV that implements the CARD class, and replace the UL with a DIV that implements he card-columns class. With a bit of CSS Styling, we end up with a nice set of boxed titles that still react to a user event.

Now, to make this server local assets for the Bootstrap libraries, for scenarios where you don't want functionality to change as things are updated, then you'd download the CSS and JS files and place them in the ASSETS folder of the application.

Then change the references to the CDN to reference "{{rootURL}}assets/" instead. Everything should just work at that point.
Bootstrap Cards

Monday, October 1, 2018

Learning Ember in VS Code -- Adding a Component

This is my continuing efforts to work with the Ember JS (www.emberjs.org) Framework. The expectation is to build a simple wish list of items.  Part one started the Ember application, part two started our first route  and part three added a Click Event to the code. Today's section works on adding a component to the system to allow for shared user interfaces.

As a programmer, I have to say that Ember components are awesome. These are user interface elements that can be shared in different places in the application. This means either on separate and distinct pages or multiple times on the same web page.

In this situation, I want to turn my list of items into an "item-list" template. Again, Ember has a generator to perform the slog work of boilerplate coding for you.

1
ember generate component item-list

This generator creates:
  1. a component JavaScript class (in app\components)
  2. the component's template (in app\templates\components)
  3. And of course a Unit Test
The first thing we need to do is move the code from our items route template over to our new item-list template. Next we want to parameterize the H2 element with the 'title' attribute. The final change is to modify the word model to the attribute "items."

The code in the item-list component template should read:

1
2
3
4
5
6
7
<h2>{{title}}</h2>

<ul>
    {{#each items as |item|}}
    <li {{action "showItem" item}}><cite>{{item}}</cite></li>
    {{/each}}
</ul>

We also have to remember that the LI has an action associated with it. Thus, we need to move that action from the items route class to the item-list component class.

So, the item-list.js file needs to look like this:

 1
2
3
4
5
6
7
8
9
10
import Component from '@ember/component';

export default Component.extend({

    actions: {
        showItem(item) {
            alert(item);
        }
    }
});

And the items.js file needs to end up looking like this:

1
2
3
4
5
6
7
import Route from '@ember/routing/route';

export default Route.extend({
    model(){
        return ['Friday', 'Dragon Riders of Pern', 'Foundation', 'Ringworld', 'RAMA'];
    }     
});

Then we need to return to the item route template, and wire it up to display our new component element.

1
{{item-list title="List of Books" items=model}}

What's going on here, is that the double curly braces indicate that this is a component, specifically the "item-list" component. The title used is the value passed into that attribute, while the array of items to use is passed into the items attribute, and is the model of the particular page.

In truth, the end result of this should show the exact page as previously, but components are an important concept to know as they allow for code re-usability.

The next entry will see about including Bootstrap into the framework.

Blog Widget by LinkWithin