or why the ASP.NET MVC 2 client validation fails when you use Microsoft.Web.Mvc (aka MvcFutures)?

There’s an incredibly useful set of extension methods in the MvcFutures called BeginForm<T>. These methods provide an alternative type-safe way of building MVC forms instead of the old string based BeginForm. Instead of:

But when you enable fantastic client side validations with the BeginForm<T> constructed form you end with a JavaScript error “Object Required” somewhere deep inside the MicrosoftMvcValidation.js:

on the line:

formElement[Sys.Mvc.FormContext._formValidationTag] = this;

The cause of this is that the new BeginForm<T> and the old BeginForm do not have a common implementation; in fact they are completely separated. The client side validation model requires all HTML forms have an ID value and also the framework expects this ID value to be set in the FormContext.FormId property of the current ViewContext. The original BeginForm does exactly this. If you don’t provide the form ID yourself, it will generate one in the form “formN” where N is the sequence number of the form.

It’s nothing difficult to fix the implementation but you must rename your extension methods to avoid conflict with the MvcFutures implementation or directly fix it in the MvcFutures and build your own version.

If you want to display a data field in your custom template instead of the default one coming with ASP.NET Dynamic Data, you can by decorating your metadata with the UIHint attribute:

[UIHint("Attributes")]
public EntityCollection<Attribute> Attributes

In this case, Attributes collection will be displayed using Attributes.ascx template. Dynamic Date is clever enough to use Attributes_Edit.ascx if you happen to edit the collection. If Attributes_Edit.ascx does not exist, Dynamic Date will use the default template.

However, if you have a template that you want to use only for editing (or inserting) and use the default template otherwise (for read only), you cannot. If you supply the UIHint, you are required to have also a read-only template – in our case, you must have Attributes_Edit.ascx together with Attributes.ascx. You end up copying the content of the default template and renaming it (to Attributes.ascx and so on). As we know that copy-paste is a bad programmer’s friend which promotes low code maintainability and readability, we must come up with another solution.

Dynamic Data delegates deciding which template to use for which field to an instance of the FieldTemplateFactory class. In particular, we are interested in its GetFieldTemplateVirtualPath method which eats a column to get the template for, mode (ReadOnly, Edit, Insert) and UIHint value. We can, of course, extend the default factory to process UIHints in the form realUIHint|mode (e.g. “Attributes|Edit” which means use the Attributes_Edit.ascx for editing but the default template for anything else). The actual code is simple: