Great minds think alike … or is it that fools seldom differ? I forget… In any note, all I can say that in this case it took three people’s work to make this possible in order to bring simplicity to the masses. Please note that this piece is a work in progress and we’re still trying to figure out how things will be at the end for these two frameworks to interact. Also, if you want more code, I suggest you check out the Fubu sample for MVC Turbine.

What does it all mean, Basil?

I’m not going to go over the details about FubuMVC, since people smarter than me have already have. All I can say is that if you’re doing MVC (the presentation pattern) style development in the .NET platform, you should definitely check out FubuMVC as well as OpenRasta and MonoRail and of course, MSMVC. These frameworks make your life easier as a web developer within the MS platform and it’s your right to explore them all to know what works for you. Ok, now to get off my soap box.

FubuMVC has tons of great features for developers to take full advantage of their web application and do a lot with very little effort.  One of these features is called Html Conventions, as Jeremy describes them:

If your familiar with MvcContrib’s Opinionated Input Builders or MVC2’s Templates feature (very well described by Brad Wilson here), we’re doing the same thing conceptually but with much different mechanics.  Right now, I’m focused on the very basic building block methods that appear on FubuMVC view’s (remember that we basically force all views in FubuMVC to be strongly typed with a single ViewModel):

  1. InputFor( expression ) – write an Html element to edit a single property on the ViewModel.  Instead of calling TextboxFor(x => x.Something) or DropdownListFor(x => x.Other) we can just say InputFor(x => x.Some.Property.On.The.ViewModel) and let the conventions figure out what to do from there.  If we need to change the model property to something else, or change our conventions about how elements should be constructed, no big deal.
  2. DisplayFor( expression ) – write an Html element to display the value of a single property value on the ViewModel.  String fields are just displayed.  Entity fields may be displayed as a link to more information on that link.  Date fields are shown in short date format, etc.
  3. LabelFor( expression ) – write an Html “label” element for the field.  Out of the box, FubuMVC will just put in the field name, but that’s not all that useful.  In our Dovetail project we have this tied into our localization subsystem to pluck out a localized header text for the desired property.

Fubu (as well as MVC Contrib and MVC2) establishes a convention (or standard) for allowing the ViewModel to drive the intent of your application.  One way they enforce this convention, is by having their own ViewPage (since they use the WebForm ViewEngine out of the box) to do some of the wiring and provide the underlying framework to make it all *just* work. The question here is, how do we get this to work on the MSMVC side? I mean, it’s just a ViewPage right??

The A Team

For a while I’ve been thinking of these pieces could be leveraged within the MSMVC world in order to provide another option for developers (and perhaps intermix solutions). While talking with Wes McClure, he mentioned some of the work that he and Ryan Ohs have done around using FubuMVC’s Html Conventions within MS MVC. The clever approach to their solution is to leverage Html helpers to bind the worlds together. This yield the following markup within your views:

Pretty cool, huh? Unfortunately, the following dark magic needs be housed within your web application in order to wire up all the pieces:

By looking at the code, and the commitment a developer had to do in order to make sure everything wired up correctly, I knew there was a better way. A way to get things done without leaking all that plumbing into an application. This cried out for application composition, so I used MVC Turbine to do the dirty work for me.

Less Is More

One of the main aspects of MVC Turbine is the Blade concept which is powered by the underlying IoC container. With all the extra wiring that needs to take place for the FubuMVC and MSMVC worlds to interact, it made complete sense for this churn to find a home within a Blade, in particular an HtmlConventionBlade:

We still need to provide the underlying plumbing for Fubu to wire up. This can be done via a supporting IServiceRegistration implementation to handle all these pieces:

From here, you're pretty much all set. All you need is to add an assembly reference to the FubuMvc.Blade and let the runtime do the rest for you. Once you have the assembly reference, you’re free to create your own HtmlConventionRegistry classes and get rolling quickly with other pieces of your application.


If you have the time, check out the source for the FubuMVC integration.  If you view the solution, you’ll see the basic CommonConventions class:

Which once it's run, yields the following output:


Feel free to play with these bits and let me know what you think. For now,

Happy Coding!