Sunday, June 29, 2014

OWIN and Katana, a first look

Since I do quite a lot of web development, I thought it a good idea to take a first look at OWIN and Katana, get a feel of what they both are about and how they can be used in a project. They are both part of a new web hosting model, where OWIN is the specification of this model and Katana is an actual implementation of this specification. In this post I will give you an overview of both and show you how you can build the basis for a web application using the Katana project.

But, let me first give you a small intro on both.

In .NET, when you build a web application, what you typically do, is use ASP .NET (either webforms or MVC) and host your application in IIS. This framework has been around for quite some time, and it has really become big. For some applications, this model can be bloated, since it runs a lot of things you don't really need in your application.

What they wanted to aim for at Microsoft with OWIN and Katana, is build a basis for a framework, that is really light weight, with just the essential things for a web application in it. And if you need extra's you just pull them in as you need them. More or less similar to what you would do to a nodejs server application. Very light weight, but also very powerful.

Along came OWIN, which is a specification for how you can build a web server that can host .NET code. It sits between a hosting environment, which in this case can be either IIS or something else, like a Windows Service, or a simple Console Application, and your actual application code. Any additional middleware, like authentication, can use the OWIN abstraction to be plugged into your application.

So, what does OWIN actually define or specify? Well, the most important part of the OWIN specification is the application delegate, which looks like this:

using AppFunc = Func<
        IDictionary, // Environment
        Task>; // Done

The application delegate has an argument of type IDictionary, which is called the environment dictionary. This dictionary contains information about one single request, its response and any relevant server state. In it, you will be able to find keys like owin.RequestMethod, which can have a value like GET or POST, or owin.RequestPath, which contains the value of the actual called URI. An overview of possible values can be found in the OWIN specification document

The second argument of the application delegate, the actual return type, is a Task, that will be returned once it has finished processing. You will see the usage of this Task once I start building up some more practical examples. What you will notice, with this task, is that the OWIN architecture is asynchronous by design.

The application delegate is a way of hooking into an OWIN server. Meaning that if you want to hook into an OWIN environment, you will need to have a method that complies to the signature of this application delegate.

Now, where OWIN is a specification, Katana is Microsoft's implementation of this specification. In Katana you can find a couple of OWIN hosts either for IIS, or for self-hosting. You will also find a couple of classes that help you with talking to OWIN, so you don't need to, for instance, take values directly from the environment dictionary. And you will also be able to find a couple of middleware components, like authentication, ...

So, let's build a small application with Katana. For this we start of with an empty console application, which we will use as a host for our application. In this we will install the OWIN self host nuget package.

Once we have this, we can start hosting an application. For this we use the WebApp class which represents the self hosting OWIN server and tell it which url it should listen on. We also give it a configuration.

The configuration class is based on convention, it needs a Configuration method that takes an IAppBuilder as an argument.

Now we can start configuring our OWIN host. First thing we will do is a very simple host, which prints out some information of the response that came in, and which returns a string that says Hello OWIN and Katana. For this we use the Run method on the IAppBuilder. This will get a context, which gives us access to the environment variable.

As you can see in the code example, the interface is async by default. The Request and Response properties give us easy access to the data in the environment variable.

When we run this example, we can go to the localhost:4321 uri. It will give us the following response:

And in our Console, we can see the method and URI printed out:

So, that's a really simple example. We can also add some preprocessing or postprocessing to our request. For this you utilize app.Use. This will take 2 arguments, the context, but also a reference to the next middleware delegate in the chain. Whatever you want to do as preprocessing you put before your call to the next delegate. Whatever you want as postprocessing, you put after the call to the next delegate.

This gives us the following output:

Another way of programming this, is with separate classes instead off with delegates. The same example than looks like this:

You create a class with an Invoke method. This method will get the environment dictionary directly. If you want to use the OwinContext instead, you can new it up. Your next delegate this time will not be passed as an argument to the Invoke function, but will be passed as a constructor argument.

With all this you can already do some nice stuff. Beware though, since the API will still be subject to changes. For people wanting to try this on non Windows machines, there's also a Nowin nuget package, that also runs on Mono. Hope this entises you to try some of this stuff out.

Sunday, February 9, 2014

Extending Durandal

Summary: combining Durandal and ASP .Net MVC, getting the best of both worlds

Experience has taught me that, when doing web projects, JavaScript is one of the technologies you will have to learn to live with. It will always be present and it will always bug you (literally). And in each project, you will have devs at your disposal who are better, or worse at writing JavaScript code. It's just a fact that, once you start writing a whole bunch of JavaScript, it can get quite messy, very quickly. 

In my recent project setup, I wanted to be able to avoid such a mess, by providing well structured JavaScript code from the beginning. But, without having to sacrifice the comfortable environment the ASP .Net MVC framework gives to my devs.

For this, I looked into a couple of JavaScript frameworks. Without treading into details here, the framework that suited my situation best was Durandal. It's not that hard to learn, it makes extensive use of RequireJS (which was already known by a lot of my developers) and it uses knockout for its bindings, which, for people coming from for instance XAML, looks quite familiar. 

For people unfamiliar to Durandal, knockout or RequireJS, you can find very good info for getting started with all three of them. 

Now, the problem with my recent project, was the combination of the good parts of ASP .Net MVC and the good parts of Durandal. For instance, what I like about ASP .Net MVC is the fact I can use statically typed helpers in my HTML. They help my devs a lot at being consistent and at keeping the error rate low(er). Kinda like what this stackoverflow question poses. So I started thinking of an easy way to accomplish this. 

My application itself will consist of little mini-SPA's. Meaning that for each part of the application, for instance the detail of a customer, or the overview of payments, ... we will make a Single Page Application (SPA). The starting point of each of these little mini-SPA's will be a .cshtml view which will get returned by an action on a controller. This .cshtml view will contain a div for the applicationHost (this is standard Durandal) and some code to start up an SPA on this page. 

As you can see, this is standard Durandal code. The only thing I did was make my own little module that sets up an SPA for a certain viewmodel, so you don't have to repeat that code over and over again in the application.

Now, what durandal does once you set up an SPA for barcode/shell, is that it starts looking for barcode/shell.js (your viewmodel) and barcode/shell.html (your view) and it links these two together. But the thing is, I actually want to set up a view in which I can use the MVC helpers. That's not possible in an HTML file. 

So, I started digging in the Durandal source code, looking for the part where the viewmodel and the view get linked together. Its in Durandals viewLocator.js file. In here, I added some extra script, giving you the ability to add an extra div (I called it applicationContent, out of convenience) in your original .cshtml file (lines 15 through 18). 

Once you start up you SPA Durandal will now look for the presence of this div and if it can find one, it will put its contents in the applicationHost div. You can now use this abbility in your .cshtml file:

As you can see I can now use things like Html.BeginForm or our Translations resource in the cshtml file. It's all placed in a div called applicationContent. Once my SPA starts up, it will place this content in the applicationHost. You also have the ability to use knockout bindings inside your applicationContent. You can see I did this for the submit binding on the form and for the pdf_url in the iframe. 

If you want to look at this extension of Durandal: I forked the project with my little addition.

Saturday, January 25, 2014

Building a cross platform solution for Windows Phone and Windows 8. Part VI: Behaviors for coping with orientation changes

Previous parts in this series:

Part 0: Intro
Part I: Quick sharing of code
Part II: The class library approach
Part III: We need a pattern
Part IV: Mocking out the differences
Part V: Event to command
Part VI: Behaviors for coping with orientation changes
Part VII: Tombstoning

In the last post we looked at an EventToCommand implementation to easily databind our events to commands, even when we don't have a Command property on a control.

In this post, I will run you through another trick, to ease the development of your views.

One of the behaviors you will probably want in your application is the ability to react to orientation changes. You can easily do this by creating an event handler for the OrientationChanged event in the code behind of your page. You will have to do this in every page you want to be able to react to orientation changes. Resulting in copies of the same piece of code all over the place.

But there is actually a more elegant way of dealing with this, and it is based on behaviors. What you can do is write a specific behavior that does nothing more than attach an event handler to the OrientationChanged event of the associated page. Based on the name of the new orientation, you can now load a specific state of you VisualStateManager.

Of course, in XAML, you now have to create the necessary VisualStateGroups for the specific orientations.

The only thing missing still is a small extra piece of XAML to make use of the OrientationChangedBehavior.

That's it, small and simple little trick. In the next part we'll look at the troubles you can have when your application needs to be tombstoned.

Other parts in this series:

Part 0: Intro
Part I: Quick sharing of code
Part II: The class library approach
Part III: We need a pattern
Part IV: Mocking out the differences
Part V: Event to command
Part VI: Behaviors for coping with orientation changes
Part VII: Tombstoning