Part III in a series of… some.

Part I covers static type checking in views and Why This Would Be Good.
Part II is about making the view architecture more naturally composable.
Part III, this article, is more narrowly concerned with return types from actions.

RenderView, Redirect and Friends

In MonoRail, ‘actions’ are the units of code which respond to an incoming page request, perform some work, then cause a view to be rendered or send a ‘redirect’—or potentially an error code—back to the client.

Actions are represented by methods on controller classes and are defined as returning ‘void’. Actions invoke a view or a redirect by calling other methods on the controller, RenderView, RedirectToAction, RedirectToUrl… and others. By default (if none of these is called) the framework will act as if the view has called RenderView(name-of-action). The parameters to the view must be placed in a global variable called PropertyBag.

This all to me seems quite unnatural.
Continue reading →

Part II in a series of… several.

In Part I I whined on about static type checking in views. Here I moan about composability of page elements.

Composability of Page Elements

Continue reading →

In work, we’ve been using MonoRail for a while. It’s a C#/.NET web application framework, and it’s very much nicer than ASP.NET, which is what I was using before.

Now I’ve had a bit of experience with it, though, there are things I would definitely change: I want the framework to allow me to compose page elements more easily, and to have stronger type-checking.

The easy one first. I’m going to talk about…

Type checking Continue reading →