In the last post I noted that the next post would describe middleware. For those unfamiliar with projects like WSGI and Rack, middleware is a module that wraps an application with additional functionality, such as logging, and is itself an application. Middlewares can add operations to the incoming request, the outgoing response, or wrap the entire process.
In the WCF Web APIs, the Channel model fulfills this role. Those are as yet unreleased in the current bits. However, the Processor pipeline offers another option. No, it doesn’t quite fit the definition above, but Processors allow you to add functionality to an app, providing a similar, if not the same outcome. Included in the current bits are an abstract MediaTypeProcessor, PlainTextProcessor, HtmlProcessor, XmlProcessor, and JsonProcesor. These can be hooked up through configuration to match an Accept header to perform conneg. Thus, your app can return any object, and the processor(s) will intercept and take care of serializing the outgoing response. Handy.
If you’ve been following other posts related to the WCF Web APIs, you’ll have likely come across Glenn Block’s roundup post that included Steve Michelotti’s post on rendering with the Razor view engine and Christian Weyer’s post describing how to configure JSON.NET as the default JSON serializer. Both are excellent examples of processors. With Christian’s permission, his JSON.NET processors, JsonNetProcessor and BsonSerialiser, were added to the WCF HTTP Contrib project.
I was recently wishing to use NHaml and thought about taking Steve’s excellent example as a basic framework. Then I took a look at Dotan Nahum’s Nina project and discovered something even better. Nina includes a view engine abstraction layer, similar in principle to Ryan Tomayko’s tilt library for Ruby. (You can find my initial efforts at extracting the view engine library on my fork.) Now, instead of supporting just one view engine, you can render using any of several supported view engines! Razor, Spark, NHaml, and NDjango are currently supported.
Here’s the code for the
ViewEngineProcessor. You’ll notice I had to extend the
MediaTypeProcessor with a generic version in order to work with the view engine api. It makes wiring things up a little messier, but nothing a clever container couldn’t handle. More work to come there.
All this is available in the WCF HTTP Contrib project. I’m sure it will develop into something a bit nicer as we progress. Also, I want to cover channels at some point, as they will offer a nicer composition mechanism for things like security, general logging, and other common middleware patterns found in the projects mentioned above.
Have you tried the WCF Web APIs? If so, please leave the team some feedback. They’d love to hear from you. Check out the contrib project while you’re at it. Want to see something in particular? File a case or contribute. And thank Darrel Miller for setting it up!
*[conneg]: content negotiation