 |
|||||||||
|
|||||||||
|
|
Templated Helpers are one of the new features in ASP.NET MVC 2. The other day, Visual Studio 2010 Beta 2 came out and some of you may have noticed that it comes pre-equipped with a beta release of ASP.NET MVC 2. In short a templated helper is a way of using various combinations of implicit and explicit rules to automatically place partial controls wherever particular data types need to appear, either in edit mode or display mode.
So let's say you have a DateTime property on your model called MeetingDate. Rather than make every single view write its own (potentially contrasting!) code to render dates in view mode and in edit mode, you can now do something like this:
<%= Html.DisplayFor( m => m.MeetingDate ) %>
<%= Html.EditorFor( m=> m.MeetingDate) %>
The DisplayFor helper will look at the data type of the thing you're looking for and try and figure out how to render that item. If you don't override convention, it will look in the Shared/DisplayTemplates folder for a DateTime.ascx control. If you want the display template to be specific to a certain controller, it can also look under the Views/(ControllerName)/DisplayTemplates folder. This same rule applies to EditorFor. It will look for the special EditorTemplates folder to try and find a suitable control. By "control" here I'm actually referring to a partial view since technically there are no controls in the traditional ASP.NET sense in MVC.
There's another HTML helper that you can use in your top-level view to invoke the partial-view location heuristics for an entire model just by doing:
<%= Html.EditorForModel () %>
This will examine the data type of your strongly-typed view and go look in an EditorTemplates folder to find the appropriate partial view.
Finally, there's another way you can supply hints to the templated helper system. That's through the use of the UIHint attribute. The UIHint actually allows you to decorate your view model (you are using an isolated view model and not working against persistance objects directly, aren't you?) with hints as to which editor should be used. This is fantastic for drop-down lists because the underlying value of a dropdown list is usually the ID of the lookup column, which is just an Int. You can't infer from Int that you want the Country dropdown vs. the State dropdown vs. the Weapons dropdown. To tell the engine which template you want, you can use the UIHint attribute as follows:
[UIHint("CustomerStatusDropDown")]
public CustomerStatus CustomerStatus { get; set; }Where CustomerStatus is another view model object that you've got with a Name/ID pair (In my case I did it this way to accomodate the data coming from an ADO.NET Data Service). When you do Html.DisplayFor on this particular property of this particular class, it will override the normal algorithm and go look for a DisplayTemplate called CustomerStatusDropdown.ascx. When you do Html.EditorFor, it will look for a file called CustomerStatusDropDown.ascx but in the EditorTemplates directory. This allows you to simply, cleanly, and elegantly control how you display and edit lookups.
If you want, you can control the template selection directly from the EditorFor method call:
<%= Html.EditorFor ( cust => cust.BirthDate, "DateTime_jQuery") %>
You might use a pattern like this in order to allow some pages to edit date/times with a jQuery picker instead of a traditional date/time picker. The possibilities are endless.
The reason why I'm blogging about this now, only a few days after Beta 2 comes out, is because I think this way of arranging your UI is so, absolutely, positively crucial to a clean, elegant, easy to maintain ASP.NET MVC application that everybody should be getting in the habit of using templated helpers now so that by the time VS 2010 hits RTM, the use of templated helpers will be old hat and we'll all be one step closer to ridding the world of "tag soup" forever.
p.s. If you invoke some of these EditorFor and DisplayFor helpers without actually having a suitable control in the EditorTemplates or DisplayTemplates directory, you might find some pretty interesting results. For example, if you do EditorForModel, and there isn't a control for that data type in your EditorTemplates directory, the system will actually use Reflection. It will sift through the public properties of your model, and for each property it will do the equivalent of invoking EditorFor and LabelFor on that property. In short, it will scaffold you up a "best guess" editor for your entire object. The reason this is in a "p.s." is because such scaffolding is great for smoke testing, but rarely lasts long.
