We were on the phone today with Scott Bellware and he asked us if we could toss together a simple MonoRail project that showed the Castle.Tools.CodeGenerator stuff in action. A few other people have been asking us to do something similar for the other things we've been discussing on our blog. So, Aaron and I sat down and pair-programmed out some source that does just that. It shows several things:

• An Action/View map is generated using Castle.Tools.CodeGenerator, and used to do view renderings, and (if desired) action redirections and the like.
• PropertyBag wrappers are created using the IDictionaryAdapterFactory code that Lee contributed.
• We show how we test our controllers using the test fixture code Aaron has been posting about.
• It has a small service layer that roughly shows how we architecture our code around here.
• It uses Windsor integration, so you can see how that's used if you've been curious.

Please keep in mind this took us about an hour to whip up and we did not actually practice full TDD with it. Enjoy!

Source

I spent yesterday and today refactoring the code for the Controller Action/View map generator tool. I made some improvements, wrote some tests and I'm pleased to announce the first release. I saw Brian had implemented his as an MsBuild task and I liked that idea, so that's how ours runs now. First, things aren't as "drop in and go" as I would like because it's still evolving in and around our, already large, code base. It's my hope that over time the tool evolves as peoples needs change, etc... we can add some more configuration, that sort of thing. I'm more than willing to hear suggestions and such. Anway, here we go...

So in order to get yourself up and running, you'll need to do a few things. First, you'll need to add the task to your MsBuild. Simply open your csproj and add the following:

          <
          UsingTask
          TaskName
          ="Eleutian.Tools.CodeGenerator.MsBuild.GenerateMonoRailSiteTreeTask"
          AssemblyFile
          ="Eleutian.Tools.CodeGenerator.dll"
          />
          <
          ItemGroup
          >
           <
          ViewSources
          Include
          ="../YourViewsDirectory/**/*.brail"
          >
           <
          InProject
          >false</InProject> </ViewSources></ItemGroup><ItemGroup> <ControllerSourcesInclude="Controllers/**/*.cs"> <InProject>false</InProject> </ControllerSources></ItemGroup><TargetName="BeforeBuild"Inputs="@(Compile)"Outputs="$(ProjectDir)\SiteMap.generated.cs"> <GenerateMonoRailSiteTreeTaskFile="SiteMap.generated.cs"Namespace="YourNamespace.SiteMap"ControllerSources="@(ControllerSources)"ViewSources="@(ViewSources)"> </GenerateMonoRailSiteTreeTask></Target>

You'll notice a few things in here. ViewSources is just the collection of view files (be it .vm or .brail, etc..). It will use the paths of those files to add the View nodes into the map. ControllerSources is the C# source files for your controllers only, specifying this helps speed up parsing. I'll get to why in a bit. And for the Sources attribute on the task you should specify all the sources in the assembly, which @(Compile) works great for.

With the task added, you should be able to build and have a SiteMap.generated.cs file, now you'll need to tweak your "base" Controller class. If you're like us, you have a Controller class that you made yourself that all of your Controller's inherit from. In that class you'll need to add some code like the following:

          private ICodeGeneratorServices _services; public ICodeGeneratorServices
CodeGeneratorServices { get { return _services; } } public RootAreaNode
Site { get { returnnew RootAreaNode(this.ControllerServices);
} } protectedvirtualvoid PerformGeneratedInitialize()
{ _services = new DefaultCodeGeneratorServices( new DefaultControllerReferenceFactory(), new AspDotNetRedirectService()
); _services.Controller = this; } 

First is the member variable, _services. You can do this however you like, but it's consumed by the ControllerAction/ViewReference classes to do various likes. CodeGeneratorServices is a property the partial controller code uses to create the MyActions and MyViews node instances. Site is just an easy way to get the top, root level node. PerformGeneratorInitialize is overridden in the partial controller classes to add the MyViews and MyActions nodes to the PropertyBag so they are available in the views. So there you go. If I'm not missing anything, that should do the trick. Let me know if I did and I'll append to this post.

Oh, the reason for specifying the ControllerSources is to cut down on the number of classes/types we visit when generating the internal "tree" that the source code is generated from. At first glance it seems like you should just be able to parse the ControllerSources only. We coudln't really do that because we needed to gather information on the other types in the assembly so we'd be able to use them in the arguments of our actions, etc... 

I have to stress that the code is relatively new, having undergone a major refactor to isolate it from the rest of our project. I make no promises that I won't have to upload a new copy, with a fix. :)

Source and Binaries

Hello everyone. I just wanted to let those who responded to the string literal posts know what was "going on". Basically, we're still trying to find a way that we can release the source to some of our tools. I apologize for dragging my feet. I manage to keep pretty busy. Heh.

I was catching up on the castle-project's mailing list and found this post by Lee Henson. He's tossed together an implementation of a PropertyBag wrapper generator and posted the source. It's very similar to our approach. One main difference is that we do our generation at runtime so we don't have to generate and reference another assembly. We have an IViewFactory interface and a PropertyBagViewFactory implementation that hands them out. In tests we have an IViewFactory that pulls the views out of the MockRepository.

Incidentally, our code that does this lies with some other code for generating Control.Invoke proxies for our System.Windows.Forms view interfaces. It seems we're not the only people who do that particular type of generation. Rüdiger Klaehn has an article here about it. I strongly suggest reading it if you do any kind of SWF work.

In the thread I found a link to Brian Romanko's post about his implementation of the controller action/view SiteMap, as well as the PropertyBag wrapper. So just in case anybody gets impatient they can find something to tinker with over there. While his implementation is different from ours, the end result is very similar. I like his idea of generating a property for actions to refer to them without parameters.

I mentioned that for the SiteMap code generation we used CodeDom. CodeDom is great and means we don't have to use StringBuilder to construct C#. It also abstracts the language away. For those who are interested in this kind of code inspection/generation, I strongly suggest taking a look at N Refactory, it's a great library for parsing C#/VB.NET source. It's what we use and I've been incredibly happy with it. The only real hurdle when doing that kind or work is type resolution. I'll try and make a post about that in the near future.

I figured I might as well continue on the string literal kick I started with my last post and talk about another situation where we've eliminated string literals. Take the following code from inside a MonoRail action method:

PropertyBag["User"] = ourUser; PropertyBag["TwoStates"]
= newstring[] { "WA", "CA" };
PropertyBag["IsAdmin"] = true;

String literals, used as keys into dictionaries carry a cetain degree of code smell (for us) and we try to avoid them. It reminds me too much code that does something similar, but in the opposite direction:

          int id = Int32.Parse(this.Params["id"])

Thankfully, this kind of code is eliminated when using MonoRail and its SmartDispatchController. We found ourselves thinking of how the same code would look in a SWF application. We would be populating views, only those views would be interfaces that the various forms/controls implemented. Well, this is exactly what we wanted in MonoRail, to wrap the PropertyBag with an interface!

After a few hours playing with Reflection.Emit, I had a code generator that would take an interface:

          public
          interface IEditMyProfileView
{ string Name { get; set; } DateTime Birthday { get; set;
} IList<TimeZone> TimeZones { get; set; } } 

And produce a class like the following:

          public
          class EditMyProfileViewPropertyBagManipulator
: IEditMyProfileView { private IDictionary _bag; public EditMyProfileViewPropertyBagManipulator(IDictionary
bag) { _bag = bag; } publicstring Name
{ get { return (string)_bag["Name"];
} set { _bag["Name"] = value; }
} public DateTime Birthday { get { return (DateTime)_bag["Birthday"];
} set { _bag["Birthday"] = value;
} } public IList<TimeZone> TimeZones { get { return (IList<TimeZone>)_bag["TimeZones"];
} set { _bag["TimeZones"] = value;
} } } 

This has the advantage of keeping our interactions with the PropertyBag as type safe as they can be. Changing the interface, breaks the build. Where as changing the type of a value inserted into the PropertyBag will (hopefully) only break tests if even that. This is another example of us trying to turn run-time failures into compile-time failures.

This kind of thing also makes tests more elegant. Instead of:

Assert.Equals("Jacob", PropertyBag["Name"]);

In our controller tests, we can continue to leverage the use of RhinoMocks to ensure the views are properly initialized:

          using (_mocks.Unordered()) { _view.Name
= "Jacob"; } _mocks.ReplayAll(); _controller.Action(); _mocks.Verify(_view);

All we've done here is created a mock from the view interface, rather than emitting the wrapper class. Again, another added benefit is if the view changes, compiling the tests will also break. The sooner things break after a change the better, and the build is pretty soon. Although, with ReSharper, it's nice to see red squiggles appear as that's even sooner.

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; } publicvirtual HomeControllerViewsNode
Views { get { returnnew HomeControllerViewsNode(this._services);
} } [System.Diagnostics.DebuggerNonUserCodeAttribute()] publicvirtual ControllerActionReference
SomeAction() { returnthis._services.ControllerReferenceFactory.CreateActionReference(this._services.Controller, typeof(HomeController), "Home", "Administrative", "SomeAction", new ActionArgument[0]);
} [System.Diagnostics.DebuggerNonUserCodeAttribute()] publicvirtual ControllerActionReference
AnotherAction(string name) { returnthis._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);
} publicvirtual HomeControllerNode
Home { get { returnthis._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()] publicvirtual ControllerViewReference
SomeAction { get { returnthis._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
{ publicvirtual HomeControllerNode
MyActions { get { returnnew HomeControllerNode(this.ControllerServices);
} } publicvirtual HomeControllerViewsNode
MyViews { get { returnnew HomeControllerViewsNode(this.ControllerServices);
} } protectedoverridevoid 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:

1. 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.
2. All URLs for redirections/transfers are always well formed and include necessary parameters with proper type checking.
3. 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.

Previously I mentioned that we switched to MonoRail for all of our new features. Well, MonoRail doesn't make page localization any easier than Web Forms does.  As a matter of fact, it actually breaks an important part of ASP.NET's localization (something I should probably submit a patch for, heh).  Basically, the DefaultResourceFactory in MonoRail creates IResources that wrap ResourceSets, which will not resolve resources to their parent resource. In other words, if you have Res.ko-KR.resx which defines String1 and Res.resx which defines String1 and String2, then calling GetString on a ResourceSet when your locale is ko-KR with String1 will work, but String2 will fail.  Calling GetString with any other locale, will return the String2 from Res.resx. To get around this, we created an IResourceFactory that returns IResources that wrap ResourceManagers instead of ResourceSets, which are capable of properly traversing the resource tree.  I'll probably submit this code soon. 

Anyways, in order to localize with MonoRail, you still need to create your resx file, add an attribute to your controller to map that resx file to something in your view's property bag, and create, name and initialize each string in your resx file.   

What we did was create a new generator like the one mentioned in my previous post that converts mybrail files to brail files.  All it does is convert this: 

${g.Test: Global Text} <br/> ${v.ViewTest:
View Text} <br/> ${c.ControllerTest:
Controller Text} <br/>

To this: 

${g.Test} <br/> ${c.Localization_ViewTest} <br/> ${c.ControllerTest} <br/> 

Now a few things happened here:

1. A file called Global.resx was created.
2. A file called Test.resx was created (Test is the name of the controller)
3. A resource called Test was added to Global.resx and initialized with the value "Global Text"
4. A resource called ControllerTest was added to the Test.resx and initialized with the value "Controller Text"
5. A resource called Localization_ViewTest (Localization is the name of the view) was added to Test.resx and initialized with the value "View Text"
6. v.ViewTest was converted to c.Localization_ViewTest

Essentially, what you end up with, is one resx for your global strings, and one resx per controller, with view specific strings being stored in the controller resx with ViewName_ prefixed to them.  There's still one piece missing to the puzzle, which is how do the views know what g and c are? Do we attribute each controller with a g resource and a c resource? No... that would be too much work for us. Instead what we do is define a new IControllerDescriptorProvider that wraps a DefaultControllerDescriptorProvider and adds appropriate ResourceDescriptors to the Resources collection of the descriptor built by the DefaultControllerDescriptorProvider.   

There is some room for improvement, like gracefully handling the case where you define and give a value for a resource twice in the same file or two seperate files, e.g. ${g.Test: Hi} ${g.Test: Hello}.  In this case, g.Test will be Hello.  In the case where they're in seperate files, it'll depend on which one was saved last (ew).  A decent way around this would be to detect this happening and pop a message box if you try to do this.

<asp:HyperLink runat="server" ID="_lnkForgot" NavigateUrl='~/ForgotPassword.aspx' Text='<%$ Resources: PageStrings, Login_lnkForgot_Text %>' />

<img src='<%= ResolveClientUrl("~/Images/img.gif") %>' />

1. Create a generator that extends Microsoft.CustomTool.BaseCodeGeneratorWithSite for .aspx files and do your preprocessing here.
   
2. Create a wizard that extends Microsoft.VisualStudio.TemplateWizard.IWizard to set up a file hiearchy like this:
   • Page.myaspx
     • Page.aspx
       • Page.aspx.cs
       • Page.aspx.designer.cs
3. Create an ItemTemplate for your item that contains these files and sets your custom tool to the generator you created in step one.
4. Add a new myaspx to your project and make sure you don't ever modify the aspx directly (this takes some getting used to)

• Add runat="server" tags to all <anything:anything> nodes that don't have it.
• Replace "~/blah" with an appropriate call to ResolveClientUrl
• Do some localization magic

<asp:HyperLink ID="_lnkForgot" NavigateUrl='~/ForgotPassword.aspx' Text="$:Forgot your Username or Password?" />

• Make databinding strongly typed.  This requires a bit of help, as you can't easily infer the type being bound by just inspecting the source.  Our solution was to add a DataType="Class" attribute to whatever the repeating control was.  For example:

  
  <asp:Repeater ID="repeater" DataType="BoundClass">
    <ItemTemplate>
      <asp:Label ID="textBox" Text='<%#@Name%>' />
    </ItemTemplate>
  </asp:Repeater>

Notice the @ in the <%#%> tag.  That gets replaced with ((BoundClass)Container.DataItem), so you can do things like <%# String.Format("{0} {1}", @FirstName, @LastName) %>

So that's how we made ASP.NET more manageable.  Now, there are still several issues with ASP.NET WebForms that caused us to eventually switch to MonoRail, which also benefits from preprocessing, but I'll post on that later.