After much effort, input, conversation, writing prototypes, re-writing prototypes, and much churn: OWIN v1.0.0 is now fully baked.

Expect to see and hear much more about this. It’s a good thing.

The generic self-host process Ghost.exe has been renamed Katana.exe and moved to its own its own git repo. It was originally in the Gate solution but that didn’t make a lot of sense in the end.

Secondly the C# http server Dragonfly.dll has been renamed Firefly.dll. There are simply too many software projects named Dragonfly. :)

Now! To jump right into a diagram.

Here is what it looks like when you have a process with a startup that wires the OWIN call up to the middleware and web frameworks you are using. At that point you have requests from the world call through that stack to your code.

Something very important here is the orange line which is the OWIN event horizon. The significance: if you want to achieve the goal of everything above the orange line being re-hostable on different server implementations, then you can’t directly reference anything from a specific server’s implementation which is below the line.

How is that accomplished in practice? By adding the Startup class to your code which is passed an IAppBuilder as an argument. Your Startup class is free to reference any web frameworks you want to use, and can chain in any middleware, and will do other one-time initialization things like construct your IoC container and configure routing. The only thing you want to avoid is compiling directly against the specifics of a particular web server, like HttpListener, Kayak, Firefly, IIS, or others. Here’s a simple example from the owin-sandbox:

using Gate.Adapters.Nancy;
using Nancy;
using Owin;
using Utils;

namespace Case05_JustNancy
{
    public class Startup
    {
        public void Configuration(IAppBuilder builder)
        {
            builder
                .Use<AppTaskDelegate>(Middleware.LogRequests)
                .RunNancy();
        }
    }

    public class HomeModule : NancyModule
    {
        public HomeModule()
        {
            Get["/"] = _ => "Hello world!";
        }
    }
}

This project compiles as a class library and in a bin subfolder. Why do that? Well – frankly – that way you are compatible with IIS and you can use existing ASP.NET hosting providers, or deploy to your existing corporate servers, without any headaches.

But beyond that, what if you want to run this same web app as a self-hosted executable without changing anything or even recompiling? That’s exactly where Katana.exe comes in. It loads and calls your Startup class directly, and also loads the http server assembly of your choosing based on a server command-line argument or OWIN_SERVER environment variable.

A quick way to see this working in the owin-sandbox is to Download as zip an extract all the files. In the base there is a click-to-start.cmd file which will compile and start all of the case studies simultaneously.

Or, if you prefer, you can also install Katana.exe with Chocolatey and run your web app from the command line directly.

cinst katana
git clone https://github.com/owin/owin-sandbox.git
cd owin-sandbox\src\Case05_JustNancy
msbuild
katana --server kayak

And if you don’t have Chocolatey installed yet, you need to fix that situation right away! :) Run the following one-liner from an admin cmd prompt:

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('http://bit.ly/psChocInstall'))"

Well, thanks again, and I hope this works well for you. The next blog post should probably be a recap of the different components that are connected to this sandbox, OWIN, Gate, Katana, Coral, Sake, etc. and talking a bit about what they do and where they live at the moment.

Looks really nice so far! Can’t believe how effective it is… Ah! You can turn off all of the "smart quote" and emoticon replacement business. :). That’s good. Now – let’s try a code block…

Yep – there’s a live writer plugin for syntaxhighlighter. Here goes:

namespace Case02_JustGate
{
    public class Startup
    {
        public void Configuration(IAppBuilder builder)
        {
            builder
                .Use<AppTaskDelegate>(Middleware.LogRequests)
                .RunDirect(App);
        }

        private void App(Request req, Response res)
        {
            res.ContentType = "text/plain";
            res.Write("You did a {0} at {1}", req.Method, req.Path);
            res.End();
        }
    }
}

Also – my request to the world – if you’re going to have an emoticon graphic in your app – please make it as simple as possible. No boggle-eyed animated yellow smiley faces donning sunglasses and whistling please. What would be wrong with taking just the characters themselves, rotating them 90 degrees, and let them keep the same color and stroke weight as the normal font?

:) becomes – know what I mean?

As you may be aware – OWIN can be thought of as a port of Rack or WSGI specification to .NET, and Gate can be thought of as a reference implementation the of Rack utility and middleware library.

If you’ve used Rack then you’re probably familiar with the rackup executable. It provides a way to load a web site and run it on a web server that doesn’t provide it’s own executable. That is more or less the role Ghost.exe plays in the overall OWIN/Gate suite.

By now you’re thinking, “That’s awesome, stop typing and tell me how to get some of that!” and the easiest way is with Chocolatey – a nuget-based software distribution mechanism. The easiest way to get Chocolatey is from the VS Package Manager Console.

Step one: get Chocolatey

PM> Install-Package chocolatey
Successfully installed 'chocolatey 0.9.8.14'.

PM> Initialize-Chocolatey
The repository is set up at 'C:\NuGet'.
The packages themselves go to 'C:\NuGet\lib' (i.e. C:\NuGet\lib\yourPackageName).
Run chocolatey /? for a list of functions.

PM> Uninstall-Package chocolatey
Successfully uninstalled 'chocolatey 0.9.8.14'.

The output text is heavily edited down – it does mention you may need to restart powershell for path changes to take effect. Actually – let’s leave VS and jump right to a new command prompt which should avoid that problem.

Step two: install ghost

C:\Users\lodejard>chocolatey install ghost
=====================================================
Chocolatey (0.9.8.14) is installing ghost (from http://chocolatey.org/api/feeds/
 OR https://go.microsoft.com/fwlink/?LinkID=206669) to "C:\NuGet\lib"
=====================================================

Step three: run ghost

This is using the OWIN web app we made in the last post.

C:\Users\lodejard>cd \Projects\Experiments\HelloEverything\HelloEverything

C:\Projects\Experiments\HelloEverything\HelloEverything>ghost --server kayak
Started at http://+:8080/

Press Esc when you want to exit the Ghost.exe – but other than that you can browse to http://localhost:8080 and see the quickstart web site we created in the last blog post in all its glory. This should work if you run Ghost with the current directory at the base path for a “web app” or “class library” project which (a) compiles it’s output to a bin directory, and (b) one of the assemblies has a public Startup class in that assembly’s base namespace.

You need to follow the (b) convention if you don’t name the Startup method on the command line. Otherwise you can start an alternate environment by providing that. In fact – let’s add simple trace logging to the Startup.Debug method. This can be edited right into the example file the quickstart added to the project.

public void Debug(IAppBuilder builder)
{
    // added to trace some request values as they pass through
    builder.Use(ShowRequests);

    builder.UseShowExceptions();
    Configuration(builder);
}

// simple user-middleware
AppDelegate ShowRequests(AppDelegate app)
{
    // this delegate is called per request
    return (env, result, fault) =>
    {
        // use a light wrapper class to access env dictionary as properties
        var req = new Request(env);

        // trace out some info
        req.TraceOutput.WriteLine(
            "{0} {1}{2} {3}", req.Method, req.PathBase, req.Path, req.QueryString);

        // and then pass all request along
        app(env, result, fault);
    };
}

You can select that configuration by running it as follows. Let’s use the firefly server this time.

C:\...\HelloEverything>ghost --server firefly HelloEverything.Startup.Debug
Started at http://+:8080/
GET /
GET /wilson
GET /wilson flip=crash

Also be sure to run Ghost /? to check out the options as well. Currently supported http servers include the default HttpListener (the default), Kayak, and Firefly. Remember to set the url acls for your port if you’re going to be using HttpListener.

C:\Projects\Experiments\HelloEverything\HelloEverything>ghost /?
Usage: Ghost [options] [<application>]
Runs <application> on an http server
Example: Ghost -p8080 HelloWorld.Startup

Options:
  -s, --server=VALUE         Load assembly named "Gate.Hosts.TYPE.dll" to
                               determine http server to use. TYPE defaults to
                               HttpListener.
  -u, --url=VALUE            May be used to set --scheme, --host, --port, and
                               --path options with a combined URIPREFIX value.
                               Format is '<scheme>://<host>[:<port>]<path>/'.
  -S, --scheme=VALUE         Determine which socket protocol server should
                               bind with. SCHEME may be 'http' or 'https'.
                               Defaults to 'http'.
  -h, --host=VALUE           Which host name or IP address to listen on. NAME
                               defaults to '+' for all IP addresses.
  -p, --port=VALUE           Which TCP port to listen on. NUMBER defaults to
                               8080.
  -P, --path=VALUE           Determines the virtual directory to run use as
                               the base path for <application> requests. PATH
                               must start with a '/'.
  -o, --output=VALUE         Writes any errors and trace logging to FILE.
                               Default is stderr.
  -v, --verbose              Increase the output verbosity.
  -?, --help                 Show this message and exit.

Environment Variables:
PORT                         Changes the default TCP port to listen on when
                               both --port and --url options are not provided.
OWIN_SERVER                  Changes the default server TYPE to use when
                               the --server option is not provided.

Looking at that, I’m absolutely certain you’re thinking the same thing Glenn Block was saying on Twitter:

@gblock: hmm I really wish there was an Owin adapter for #aspnetwebapi! /cc:@loudej

Wish no longer! Gate has a new drop available, version 0.3.4, and it contains a Get.Adapters.AspNetWebApi package which does exactly that – enabling you to mix the Web API into your OWIN based web applications.

Let’s take a look at how that feels. That should be even easier than before because of a few more things that are new in Gate – a handful of Quickstart nuget packages, and a Ghost “generic host” process which lets you use any of the available OWIN http servers interchangeably. Neat, right? Let’s jump right into that!

First – start with a new “ASP.NET Empty Web Application”

Then – to make it “really empty” – let’s remove a bunch of references. This step is optional, but should be very satisfying if you want to see some minimalism in action. Quickest way is to select the last assembly reference and lean on the “delete” key.

Finally let’s add the meta-package Gate.Quickstart.AspNetWebApi from Nuget.org.

PM> Install-Package Gate.Quickstart.AspNetWebApi
Attempting to resolve dependency 'Gate.Quickstart.Core (≥ 0.3.4)'.
Attempting to resolve dependency 'Gate.Hosts.AspNet (≥ 0.3.4)'.
Attempting to resolve dependency 'Gate.Builder (≥ 0.3.4)'.
Attempting to resolve dependency 'Owin (≥ 0.7.0)'.
Attempting to resolve dependency 'Microsoft.Web.Infrastructure (≥ 1.0.0.0)'.
Attempting to resolve dependency 'Gate.Middleware (≥ 0.3.4)'.
Attempting to resolve dependency 'Gate (≥ 0.3.4)'.
Attempting to resolve dependency 'Gate.Adapters.AspNetWebApi (≥ 0.3.4)'.
Attempting to resolve dependency 'AspNetWebApi.Core (≥ 4.0.20126.16343)'.
Attempting to resolve dependency 'System.Net.Http.Formatting (≥ 4.0.20126.16343)'.
Attempting to resolve dependency 'System.Net.Http (≥ 2.0.20126.16343)'.
Attempting to resolve dependency 'System.Web.Http.Common (≥ 4.0.20126.16343)'.
Attempting to resolve dependency 'System.Json (≥ 4.0.20126.16343)'.

You can now press F5 and see this run. The quickstart adds an example Startup class -which is using a partial class trick because I wanted you to be able to add more then one demo to the same project. But that’s not really necessary – in your own projects a simpler Startup class like this would work exactly the same.

using System.Net;
using System.Net.Http;
using System.Web.Http;
using Gate.Adapters.AspNetWebApi;
using Owin;

namespace HelloEverything
{
    public class Startup
    {
        public void Configuration(IAppBuilder builder)
        {
            var config = new HttpConfiguration(new HttpRouteCollection("/"));

            config.Routes.MapHttpRoute(
                "Default",
                "{controller}",
                new {controller = "Main"});

            builder
                .RunHttpServer(config);
        }

        public void Debug(IAppBuilder builder)
        {
            builder.UseShowExceptions();
            Configuration(builder);
        }
    }

    public class MainController : ApiController
    {
        public HttpResponseMessage Get()
        {
            return new HttpResponseMessage(HttpStatusCode.OK)
            {
                Content = new StringContent("Hello, AspNetWebApi!")
            };
        }
    }
}

Next you should try adding the meta-meta-package Gate.Quickstart.All. Then you’ll be able to press F5 to see a demo of everything and the kitchen sink: Web API, Nancy, SignalR, Gate “test page”, and Direct output from code (res.Write style).

Direct output is kind of interesting, looks like this:

    public class Startup
    {
        public void Configuration(IAppBuilder builder)
        {
            builder.RunDirect((req,res) =>
            {
                res.ContentType = "text/plain";
                res.Write("Hello, ").Write(req.PathBase).Write(req.Path).Write("!");
                res.End();
            });
        }
    }

Well – that’s probably long enough for this post. Next topic – hopefully soon – will be about using the Ghost.exe “generic host” to run this web application on HttpListener, Kayak, or Firefly.

This one is to introduce Dragonfly – which is another 100% C# HTTP server. It’s designed from the ground up to be an OWIN host, of course, and is entirely non-blocking. This is similar to other open source managed web servers like Kayak and to some extent others like Manos.

Why start another C# HTTP server? Well, to some extent this started as an exercise to have another test harness to help troubleshoot and validate Gate and OWIN, rather than as a functional HTTP server of its own. It has from that grown into something that I felt had enough value to share as a standalone project.

So! To try this in a console project:

PM> Install-Package Dragonfly
Attempting to resolve dependency 'Gate.Owin (≥ 0.2.1)'.
Successfully installed 'Gate.Owin 0.2.1'.
Successfully installed 'Dragonfly 0.2'.

PM> Install-Package Gate
Attempting to resolve dependency 'Gate.Owin (≥ 0.2.1)'.
Successfully installed 'Gate 0.2.1'.

And here’s a little sample.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using Gate.Owin;

namespace DragonflySample
{
    class Program
    {
        static void Main(string[] args)
        {
            // Sinking the trace is optional, just wanted to show it
            var server = new Dragonfly.Http.ServerFactory(new ConsoleTrace());

            // Create takes an OWIN AppDelegate and port or endpoint.
            // It returns an IDisposable.
            using (server.Create(App, 8080))
            {
                Console.WriteLine("Running at http://localhost:8080/");
                Console.WriteLine("Press enter to exit");
                Console.ReadLine();
            }
        }

        class ConsoleTrace : Dragonfly.Utils.IServerTrace
        {
            public void Event(TraceEventType type, Dragonfly.Utils.TraceMessage message)
            {
                Console.WriteLine("[{0} {1}]", type, message);
            }
        }

        static void App(
            IDictionary<string, object> env,
            ResultDelegate result,
            Action<Exception> fault)
        {
            // some classes in Gate.dll make using OWIN directly a bit easier
            // but in practice you'll probably use a web framework rather than
            // write directly like this

            var request = new Gate.Request(env);
            var response = new Gate.Response(result);

            response.Headers["X-Foo"] = new[] { "Bar" };
            response.ContentType = "text/html";

            response
                .Write("<html>")
                .Write("<head><title>Hello Dragonfly</title></head>")
                .Write("<body>")
                .Write("<h1>Hello Dragonfly</h1>")
                .Write("<p>You are looking at ")
                .Write(request.Path) // NOTE: this is not url encoded!!!
                .Write("</p> <!-- thanks, Nick -->")
                .Write("</body>")
                .Write("</html>");

            response.Finish();
        }
    }
}

The topic of this post is OWIN – specifically the 0.2.1 refresh of the Gate reference implementation which has been released to NuGet.org.

You can test-drive these bits yourself, if you would like, from a simple C# console application. I’m assuming you have NuGet installed, right? Good! So in a new console app (HelloWorld.exe in my case) from the Package Manager Console install either Gate.Stack.Kayak.Nancy or Gate.Stack.HttpListener.Nancy. You can also right-click the project and select Manage NuGet Packages… to accomplish the same thing. The various Gate.Stack.* you will find are umbrella packages that pull in several dependencies and add a few example source files.

Package Manager Console Host Version 1.6.21215.9133

Type 'get-help NuGet' to see all available NuGet commands.

PM> Install-Package Gate.Stack.Kayak.Nancy
Attempting to resolve dependency 'Gate.Hosts.Kayak (≥ 0.2.1)'.
Attempting to resolve dependency 'Gate.Builder (≥ 0.2.1)'.
Attempting to resolve dependency 'Gate.Owin (≥ 0.2.1)'.
Attempting to resolve dependency 'Kayak (≥ 0.7.2)'.
Attempting to resolve dependency 'Gate.Adapters.Nancy (≥ 0.2.1)'.
Attempting to resolve dependency 'Nancy (≥ 0.9.0)'.
Attempting to resolve dependency 'Gate.Middleware (≥ 0.2.1)'.
Attempting to resolve dependency 'Gate (≥ 0.2.1)'.

You’ll also notice Example-Startup.cs and Example-KayakStarter.cs have been added. We can look at those in a bit – but first let’s add some code to the Program.Main method.

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Running on http://localhost:8080/");
            KayakStarter.Start(8080, true);
        }
    }

    public class HomeModule : Nancy.NancyModule
    {
        public HomeModule()
        {
            Get["/"] = _ => "Hello, Kayak and Nancy!";
        }
    }
}

Now you can run with F5 and browse to http://localhost:8080/ – Bam! I won’t spoil the surprise about what you should expect to see. Let’s also take a quick look at what the two example files are doing.

using System;
using System.Net;
using Kayak;

namespace HelloWorld
{
    public class KayakStarter : ISchedulerDelegate
    {
        public static void Start(int port, bool debug)
        {
            Gate.Hosts.Kayak.KayakGate.Start(
                new KayakStarter(),
                new IPEndPoint(IPAddress.Any, port),
                debug ? "HelloWorld.Startup.Debug" : "HelloWorld.Startup");
        }

        public void OnException(IScheduler scheduler, Exception e)
        {
        }

        public void OnStop(IScheduler scheduler)
        {
        }
    }
}

This is the static Start method we’re calling from Main. It’s calling the Gate host glue for Kayak, and it also implements the ISchedulerDelegate interface to be notified of a few critical events from the Kayak server. The final string argument is also interesting – it is passed to the Gate.Builder assembly and is used to discover and call the Startup method. Let’s take a look at that Startup method next.

using Gate.Adapters.Nancy;
using Gate.Middleware;
using Gate.Owin;

namespace HelloWorld
{
    public static class Startup
    {
        public static void Configuration(IAppBuilder builder)
        {
            builder
                .RunNancy();
        }

        public static void Debug(IAppBuilder builder)
        {
            builder
                .UseShowExceptions()
                .RunNancy();
        }
    }
}

Beautiful, no? :)

The IAppBuilder is the only interface defined by the OWIN reference implementation assembly (Gate.Owin.dll) and it really only has two methods named Use and Build. Your Startup method doesn’t call those directly, rather you will use the extension methods coming from Middleware and Framework Adapter assemblies you have chosen to add to your application. UseShowExceptions comes from Gate.Middleware.dll and RunNancy comes from Gate.Adapters.Nancy.

In terms of timing you can think of this as the OWIN version of the Global.asax‘s Application_Start method. The IAppBuilder itself is simply stitching together a pipeline, and is something you can think of as the moral equivalent of Ruby’s Rack, or Node’s Connect module. It’s the result of the efforts of the .NET HTTP Abstractions group endeavoring to establish a comparable standard for .NET platform.

It’s spring again, Easter weekend, and we’re celebrating with Brenda’s sister Michelle and niece Azaria. They’re staying with us while they transition to Washington.

Other news on a professional front, Orchard 1.1 has been released! Time to dig in for 2.0 scope and ideas.

Ah! Also will be in Atlanta for a TechEd presentation on “Writing an ASP.NET MVC ViewEngine” so if you’re in town be sure to check that out.

Another thing going on is some community development participation work on the Gate reference implementation of the OWIN spec. It’s a lot if fun – you should check that out.

Well, that’s good for now. Lets see if this mobile blog app actually posts. :)

Posted from WordPress for Windows Phone

So here are some thoughts.

Displaying Variable Content

Original

${Html.Encode(ViewData["Message"])}

Spark auto-encodes if you enabled that, so you wouldn’t need the Html.Encode.

${ViewData["Messages"]}

You can also declare property accessors to view data dictionary.

<viewdata Messages="string"/>
${Messages}

Conditions

Original

<if condition='DateTime.Now.Hour > 20 || DateTime.Now.Hour < 6'>
  <p>It's bed time!</p>
</if>
<else>
  <p>Party!</p>
</else>

There’s yet another way of doing conditions when else/if and else are involved that I kind of prefer, personally.

<test if='DateTime.Now.Hour > 20 || DateTime.Now.Hour < 6'>
  <p>It's bed time!</p>
<else/>
  <p>Party!</p>
</test>

and there’s also inline code support if you prefer

# if(DateTime.Now.Hour > 20 || DateTime.Now.Hour < 6) {
  <p>It's bed time!</p>
# } else {
  <p>Party!</p>
# }

Loops

Original

<var list='new List<String>() { "WebForms", "Razor", "Spark", "NHaml" }'/>
<ul>
  <li each='var item in list'>
    ${item}
  </li>
</ul>

Loops looks pretty good, though (as always) if you prefer to inline code you could also use something like the following

# var list = new List<string>() { "WebForms", "Razor", "Spark", "NHaml" };
<ul>
# foreach (var item in list) {
  <li>${item}</li>
# }
</ul>

Displaying a Form

Original

<viewdata model="MvcApplication1.Models.LogOnModel"/>

# using (Html.BeginForm()) {
    ${Html.ValidationSummary(true, "Login was unsuccessful.")}
    <div>
        <fieldset>
            <legend>Account Information</legend>

            <div class="editor-label">
                ${Html.LabelFor(m => m.UserName)}
            </div>
            <div class="editor-field">
                ${Html.TextBoxFor(m => m.UserName)}
                ${Html.ValidationMessageFor(m => m.UserName)}
            </div>

            <div class="editor-label">
                ${Html.LabelFor(m => m.Password)}
            </div>
            <div class="editor-field">
                ${Html.PasswordFor(m => m.Password)}
                ${Html.ValidationMessageFor(m => m.Password)}
            </div>

            <div class="editor-label">
                ${Html.CheckBoxFor(m => m.RememberMe)}
                ${Html.LabelFor(m => m.RememberMe)}
            </div>

            <p>
                <input type="submit" value="Log On" />
            </p>
        </fieldset>
    </div>
# }

This one is particularly interesting if you use the new bindings feature to create tags for your favorite helpers.

<viewdata model="MvcApplication1.Models.LogOnModel"/>

<Form>
    <ValidationSummary ExcludePropertyErrors="true">
        Login was unsuccessful.
    </ValidationSummary>
    <div>
        <fieldset>
            <legend>Account Information</legend>

            <div class="editor-label">
                <Label For="UserName"/>
            </div>
            <div class="editor-field">
                <TextBox For="UserName"/>
                <ValidationMessage For="UserName"/>
            </div>

            <div class="editor-label">
                <Label For="Password"/>
            </div>
            <div class="editor-field">
                <Password For="Password"/>
                <ValidationMessage For="Password"/>
            </div>

            <div class="editor-label">
                <CheckBox For="RememberMe"/>
                <Label For="RememberMe"/>
            </div>

            <p>
                <input type="submit" value="Log On" />
            </p>
        </fieldset>
    </div>
</Form>

Conclusions

So – as with all things – each of the view engines will have lots of ways to approach any problem. Just wanted to add some of my own personal preferences to the mix for the Spark column out of band. Thanks again to Shay Friedman for writing up the comparison, and also for his work supporting IronRuby.

It takes a large leap of faith to retrofit the rendering system of an application. If the retrofit is based on significantly different concepts you don’t really have a choice but to enter a period of almost total loss of functionality. So here we are – jumping the canyon – looking forward to getting all of the modules back online over a new display system.

There are a lot of things we want to accomplish with what’s being designed. Trying to capture as many of the simple qualities you’d want from a direct template based approach along with the flexibility, power, and control you’ll need in a system like Orchard.

To that end we’re taking a lot of proven concepts and patterns, and bringing them all together as cleanly and transparently as possible with the tools we have at our disposal. Much of this will be leaning heavily on the IoC capabilities under Orchard’s extensibility story, and the dynamic capabilities provided by the upgrade to the latest dotnet fwk.

At the heart of the beast are some very old patterns. The most significant one is the Two Step View which: Turns domain data into HTML in two steps: first by forming some kind of logical page, then rendering the logical page into HTML. Looking at this one way you could think of this as a form of ViewModel. Looking at it another you could say this is a WebControl style approach. The goal is to be something in-between that’s not really one or the other.

This approach has very large implications in the way Orchard controllers and views relate to each other. There is a degree of overhead to using strongly typed view models – I like them myself but they are an additional class to create. An even larger problem – they are only meaningful to code that has a strongly typed compile time knowledge of their existence. Know what I mean? If you’re a module that wants to monitor or alter material as it’s displayed there’s not much you can do without getting heavily into reflection, and even then you’re not really free to alter the page results beyond manipulating the data within the bounds of the declared viewmodel structures.

For those reasons we explored and are delving into the use of dynamic object behaviors layered on top of normal clr types as the basis of a “Shape” page object model. The idea of a shape is to be a representation of the domain model that’s halfway into the page display vernacular – it shows a hierarchy that reflects logically what will be rendered, carries forward the information from the domain model in a way that’s still connected to it’s source, and may carry forward some rendering-specific information (like css classes and additional html attributes) but stops short of determining or being connected to the specific html that will be produced.

That last point is key – and it is the quality that stops the page object model from being compared to a web control rendering approach. Each web control knows how to render itself, that’s its job, but in this case the task of converting the shapes into html is a seperate concern. Essentially implementing a Strategy and Adapter pattern, there is a display manager available via @Display(anyShape) which will use the appropriate template or method to render the given shape.

It’s really nice, too, the fact that it can be any template or method. So if you have a Message shape, for example, the realization of shapes of type “Message” could be bound against either a view template like Message.cshtml or a public method on an IoC component with the [Shape] attribute. You can override or augment the description of a shape’s binding in modules or in your theme as well – the [Shape] method for the default Message rendering method in a module can be overridden with a Message.cshtml template in the active theme.

Of course this doesn’t mean a page object model will be returned from all controller actions in Orchard – it would be counterproductive to go to that extreme. But it’s a great way of representing information that is meant to be explored and manipulated by code from other modules. Forms that are expected to be extensible, for example, or the contents of page zones like sidebars. Where to use it, and what set of core shapes and their granularity, is all part of the art of software design in comparing alternatives.