Archive for the ‘Code Things’ Category

Ampersandjs and ASP.NET MVC

Thursday, November 13th, 2014

Ampersand is a newish client JavaScript framework that helps build native web applications. It is built and maintained by &yet. Ampersand is different than other frameworks because it is not a monolithic library that solves all your problems. It is a collections of small modules that all solve a single problem that when put together make up Ampersand. This allows you to easily switch out modules that don’t work for you. To read more about Ampersand and its benefits check out the following links.

I recently wanted to know what it would take to run the Ampersand-cli demo app using ASP.NET MVC instead of node.js. So I did just that. The can be found on my github. Head over there and check it out. What follows is some the key points that is a bit different than the node.js version.

Getting Started

Node.js is required when setting up my demo code. It is not required but I used it because it is easier if you do. Node allows us to use npm and tools like gulp and browserify which we will cover in a bit.

First we need to install gulp and browserify from npm. Navigate to the WebApp root folder from the command line and run:

npm install -g gulp browserfiy

Next install all the dependencies found in the package.json from npm by running

npm install

Next run gulp.

gulp

Finally build and run the visual studio project.

Browserify and gulp 

Ampersand highly suggests to use a common JS loader like browserify. In my example, I followed this suggestion. Browserify is a commonJS loader that allows you to require(”) modules, like node, in the browser. Gulp is a streaming build system that allows you to run jobs such as pre-compiling CSS, copying files, and many other things.

When browserify is pointed at our main app.js file (Scripts\App\app.js) and run, it will bundle all of the app’s JavaScript files into one file (Scripts\app.bundle.js).

Gulp and the corresponding gulpfile.js is used to watch the JavaScript files and automatically run browserify when things change. This means that as you edit files, gulp will rebuild the app.bundle.js file. All you have to do is reload the browser to get the final results.

Routes

With any native web application frame, the odds are good you are doing routing on the client side. Which means the server must serve the same html, css, and js for any page that is request. To do this, a catch all route is created.

routes.MapRoute(
    name: "Default",
    url: "{*.}",
    defaults: new { controller = "Home", action = "Index"}
);

Base Layout and Action

Notice the _Layout.cs file is basically empty. This is because everything is loaded via Ampersand including anything in <head>. This also means that our default controller and action serve nothing. The only things our default action needs to serve is any CSS and JavaScript.

Templates

Ampersand’s demo site uses Jade templates and complies them at runtime down to a single template.js file. Meaning that all HTML is served to the user the first time the application loads. In my examples, I sort of replicated this by creating an Action that creates a single JS file with all the HTML templates. This can be better and more automated but for the purposes of this demo I stopped here to show a direction that could be taken.

See the Template Controller and the views in the Template view folder.

Templates do not need to be served this way. You could make HTTP get requests for them in Ampersand. I did it this way to keep in the spirit of the original demo.

Sample API

The simple API was created using Web API. Nothing really different going on here expect that because of C# our models are strongly typed.

CSS

The original Ampersand demo used stylizer and a CSS preprocessor. I took the output from that and put it into site.css. You could do whatever suits your needs here.

Final things to Note

In this code, the app.bundle.js and template JavaScript is not far future cached. It could be. That is something you will need to figure out. There are many different ways to do this in MVC, I did not want to suggest one. The same goes for the CSS.

Much like Nuget’s packages folder, the node_modules folder is not checked into source control. Running npm install command will repopulate this folder much like Nuget’s auto restore.

Other than what is about, the rest of the application is vanilla Ampersand, no other changes were made.

Source Code: https://github.com/Oobert/Ampersand-and-ASP.NET-MVC/tree/master

C# HttpClient integrated authentication

Monday, July 14th, 2014

HttpClient has become the standard way to make http requests in C#. This is mainly used for API calls but has other uses as well. Recently, I have had to make http requests to servers that require authentication and the documentation on how to do this is scattered. The funny part is that it is really easy to do.

var uri = new Uri("<url>");

var credentialCache = new CredentialCache();
credentialCache.Add(
    new Uri(uri.GetLeftPart(UriPartial.Authority)),
            "<auth method>",
            new NetworkCredential("<user name>", "<password>", "<domain>")
            );
            

HttpClientHandler handler = new HttpClientHandler();
handler .Credentials = credentialCache;
var httpClient = new HttpClient(handler );

var response = httpClient.GetAsync(uri).Result;

can be basic, digest, ntlm, or negotiate. Then just updated the Network Credentials to that of the user you want to make the call and you are good to go.

It appears that kerberos on its own does not work. This may be because of my server configuration. However if you use negotiate, HttpClient will use kerberos if the server is configured for it otherwise it will fallback to NTLM.

So I wrote a state machine. Why? Because it sounded fun!

Friday, February 7th, 2014

I had a problem. I was tasked to make a wizard type interface for a few workflows in an web app. The workflows had 3+ steps with the current max number of steps at 10.

Options

Option 1: I could control state on the server. After every step in the workflow the data of that step would be posted to the server where the server would keep track of it in session and take the user to the next step. This is very doable, and is pretty much how web apps have functioned before ajax. The downside to this is controlling partial state on the server is hard because session management is hard. You have to account weird scenarios like what happens if the user starts the same workflow in a different browser window, you now have to somehow identify what window goes to what session. Or how do you know when to clear a workflow in progress because the user navigated to a different page in the web app. What happens if they come back? All of these question can be fixed in some form but normally involve a lot of if statements.

Option 2: Wouldn’t it be easier to keep all workflow data on the client until the workflow was completed? Yes, yes it is. However this means that the client can no longer do full page reloads between steps. No problem, there are frameworks that cover this such as Angular.js. In my solution, I am loading and unloading html templates into the DOM manually and using Knockout.js for data binding. Why did I roll my own this way? Because IE8 but that is a different blog post. By keeping all the workflow state in the browser, we have less issues to deal with but a few new ones come up. For example, do you care that the user has to start over if they hit refresh? Do you need the browsers back button to work? These were easy for my use cases, it didn’t matter at the moment because of how this will be used in production. I started down this road, things were going well. But then I noticed that my JavaScript was getting kind of cluttered with if statements such as…

if (here) do this
else if (over there) do that
else if (holy crap) I have no idea
else if (another one?) and I am lost

Option 2b: State machines! About 2 steps into the first workflow, I noticed a pattern. Every step in a workflow loaded something, waited for the user to do work, moved to the next step. The lightbulb went off and I started looking at state machines in JavaScript. I found many like machina.js and npm had many in there as well. machina.js being the first in my search results, I went with it. It looks good and probably would have solved my problem but it has(had?) a dependency on underscore.js Due to the nature of this project, introducing an external library is time consuming, introducing two is a huge pain. But, you guessed it, that is another post someday. In the end, I decided to build my own. Why? Because it sounded fun, also I didn’t need a full featured library, yet.

Code!

So I wrote a state machine. It had a few requirements there were identified upfront.

  • Know what was the current state
  • Be able to change to a new state
  • Call an unload method on the old state
  • Call a load method on the new state
  • Pass data to the new state
  • Be able to generically call methods on the current state

Over time, I am sure the requirements will grow and we will make the choice of growing this code base or moving to a more feature complete option. And here it is.

    var fsm = function (states) {
        this.current;
        this.states = states;
    };
 
    fsm.prototype.changeStateTo = function (newState, obj) {
        if (this.current &&
            this.current.unload) {
            this.current.unload();
        }
 
        
        if (this.states[newState]) {
            this.current = this.states[newState];
 
            if (this.current.load) {
                this.current.load(obj);
            }
        }
    }
 
    fsm.prototype.callAction = function (action, obj) {
        if (this.current[action])
            this.current[action](obj);
    }

As you can see, the state machine takes in an object that is the different states that it can be. A usage example is below.

The changeStateTo function will call unload on the current state, and then call load on the new state. It has some light error checking to make sure states and methods exist before continuing.

The callAction method is a generic way to call a specific action (function) on the current state. An example of this would be if there is a button that is on every screen, you could use this method to call that action when it is pressed on the current state.

And a small example of usage.


    var myFsm = new fsm({
        state1:{
            StateRelatedObject: { 
              text: "hello"  
            },
            load: function ()
            {
                //do work like load template or show/hide page elements
            },
            StateRelatedFunction: function()
            {
                //do specific work related to this state.
                //can access objects or methods on current state like...
                this.StateRelatedObject.text = "hello world";
            },
            unload: function()
            {
                //clean up after yourself here.
            }
        },
        state2:{
            load: function () { },
            StateRelatedFunctionOrObjects: function() { },
            unload: function(){ }
        }
    })
    
    myFsm.changeStateTo("state1");
    
    myFsm.callAction("StateRelatedFunction", { /* data in here */ });


The object that is passed into the state machine can get rather large. This is ok because it is segmented into it different states and is well organized.

Testing is pretty easy too!


    //setup test parms here.

    myFsm.state1.StateRelatedFunction();

    //do asserts on data here.
    //example: myFsm.state1.StateRealtedObject.text === "hello world";

Enjoy!

Edit 03/06/2014: I fixed a misspelling in code. I also posted a complete code example to github.
https://github.com/Oobert/LittleStateMachine