I was trying to think of a way to introduce this post, and I realize that here at Eleutian, we hate strings. We don't hate all strings, it's mostly string literals that we hate. Not even all string literals. But most of them. A good portion of the work we do to make our code more solid involves removing string literals. Anybody familiar with MonoRail has seen lines similar to the following:
RenderView("Home", "Action");<a href="${siteRoot}/Home/Action.rails">...</a>
${UrlHelper.LinkTo("Home", "Action")}
And so on, see all those string literals that refer to things that aren't really string literals? At first glance, we can get rid of the Controller string by doing something with typeof(HomeController).Name and chopping off the Controller suffix. That'd be an ugly static method call everywhere and still leaves "Action" to be dealt with. We want things to break if HomeController changes names and we want to know where HomeController is referenced.
One of our rules is to turn potential run-time errors into potential compile time errors if at all possible.
It's funny, but the compiler is our first test, and a good one at that. We found ourselves using those controller names, area names, and action names in a variety of situations - redirections, view rendering, generating url's in the views, etc... Anytime I see this I'm annoyed:
Redirect("AnotherAction.rails?parameter=34");
or even worse:
Dictionary query = new Dictionary();
query["parameter"] = 34;
Redirect("AnotherAction.rails", query);
You'll notice that our life would be much easier if methods were first-class objects. They aren't in C# 2.0... or even in 3.0 (without lambda functions) and so this is where we are.
Aaron and I talked things over, complaining on end about how frustrating things were. Our problem boiled down to turning the controller action's into something we could reference, so we decided to try a little code generation magic. We wanted to be able to write code like the following:
MyActions.Action().Render()
Site.AdministrativeArea.Home.Action(24, "Jacob").Redirect()
And so on. In order to do this we have a tool that runs as a pre-build step that does the following:
- Walks the source tree, parsing *.cs files, looking for controllers. We have to parse source, we can't use reflection because the same source files we're parsing will be using this generated code.
- Look for public methods (the actions) on the controller.
- Generates a class (HomeControllerNode) that has a method, with the same prototype as the action, that returns a ControllerActionReference:
public partial class HomeControllerNode {
private IControllerServices _services;
public HomeControllerNode(IControllerServices services) {
this._services = services;
}
public virtual HomeControllerViewsNode Views {
get {
return new HomeControllerViewsNode(this._services);
}
}
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public virtual ControllerActionReference SomeAction() {
return this._services.ControllerReferenceFactory.CreateActionReference(this._services.Controller, typeof(HomeController),
"Home", "Administrative", "SomeAction", new ActionArgument[0]);
}
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public virtual ControllerActionReference AnotherAction(string name) {
return this._services.ControllerReferenceFactory.CreateActionReference(this._services.Controller, typeof(HomeController),
"Home", "Administrative", "AnotherAction", new ActionArgument[] {
new ActionArgument("name", typeof(string), name)}); }
}
}
- Generates a stub class for area's with properties for each controller in that area (they return HomeControllerNode instances) We introduce a default root area that all top level controllers and other areas are children of:
public partial class AdministrativeAreaNode {
private IControllerServices _services;
private HomeControllerNode _home;
public AdministrativeAreaNode(IControllerServices services) {
this._services = services;
this._home = new HomeControllerNode(this._services);
}
public virtual HomeControllerNode Home {
get {
return this._home;
}
}
}
- Walks the Views subdirectory looking for *.brail files mapping them onto their controllers.
- Generates a class (HomeControllerViewsNode) with methods for each view that return a ControllerViewReference.
public partial class HomeControllerViewsNode {
private IControllerServices _services;
public HomeControllerViewsNode(IControllerServices services) {
this._services = services;
}
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public virtual ControllerViewReference SomeAction {
get {
return this._services.ControllerReferenceFactory.CreateViewReference(this._services.Controller, typeof(HomeController),
"Home", "Administrative", "SomeAction");
}
}
}
- Generates a partial class for the controller class itself with two properties - MyViews and MyActions that return the ControllerNode and ControllerViewsNode instances for that controller.
public partial class HomeController {
public virtual HomeControllerNode MyActions {
get {
return new HomeControllerNode(this.ControllerServices);
}
}
public virtual HomeControllerViewsNode MyViews {
get {
return new HomeControllerViewsNode(this.ControllerServices);
}
}
protected override void PerformGeneratedInitialize() {
base.PerformGeneratedInitialize();
this.PropertyBag["MyViews"] = this.MyViews;
this.PropertyBag["MyActions"] = this.MyActions;
}
}
In the generated code, we pass a reference to an IControllerServices implementation down through the hierarchy, which provides the ControllerReferenceFactory that creates the ControllerActionReference and ControllerViewReference objects. Our EleutianController class has a property on it - Site, that returns the RootAreaNode so the top of the site can be reached from anywhere. This is also always placed into the controller's PropertyBag, along with MyActions and MyViews. The PerformGeneratedInitialize method, that's called in our base class so that each controller can add it's own MyViews and MyActions, which don't live in the base class.
Our ControllerActionReference class has Redirect and Transfer methods as well as a Url property. So now we can do the following:
<a href="${Site.HomeController.Action(200, true).Url}">...</a>
ControllerViewReference has a Render method that does the appropriate RenderView call on the controller. Now we've accomplished a lot of things:
- No more string literals. If we rename something, the build fails. Our views will fail when they're opened and not when links are followed, it is pretty easy to test that a view compiles.
- All URLs for redirections/transfers are always well formed and include necessary parameters with proper type checking.
- Provided ourselves with Intellisense when building URLs in tests and controllers. (Sexy? Yes.)
Speaking of testing, in our controller tests we have a custom IControllerReferenceFactory that returns mock ControllerActionReference instances (via RhinoMocks) So now redirections, transfers and view renderings are just mocked method calls:
using (_mocks.Unordered())
{
_controller.MyViews.AnotherView.Render();
}
_mocks.ReplayAll();
_controller.SomeActionThatRendersAnotherView();
_mocks.VerifyAll();
Which is much cleaner than string comparisons on _controller.SelectedViewName, especially if a redirect with parameters is expected in an action. This has simplified our life and given us incredible peace of mind, well worth the time to implement - which was relatively simple. Whew.