Steve Sanderson’s blog

In the previous post I showed a fairly straightforward way to create an editor where the user can add and delete the items in a set. Please read that previous post before continuing to read this one.

But what about validation? We don’t like your blank item names or your negative prices, sonny!

As you probably know, ASP.NET MVC 2 supports DataAnnotations attributes out of the box, so you can mark up your model as follows.

public class Gift
{
    [Required]
    public string Name { get; set; }
 
    [Range(0.01, double.MaxValue, ErrorMessage = "Please enter a price above zero.")]
    public double Price { get; set; }
}

Server-side validation

Server-side validation is trivial, assuming you want to use the default model binder convention of validating each model object when it’s bound. In the action that receives the form post, just check ModelState.IsValid, and refuse to accept the data if it isn’t.

[HttpPost]
public ActionResult Index(IEnumerable<Gift> gifts)
{
    if (ModelState.IsValid)
        return View("Completed", gifts);
    else
        return View(gifts); // Redisplay the form with errors
}

You’ll also need to specify where the validation error messages should appear. Update the GiftEditorRow.ascx partial by placing a couple of Html.ValidationMessageFor() helpers somewhere inside the row.

<%= Html.ValidationMessageFor(x => x.Name) %>
<%= Html.ValidationMessageFor(x => x.Price) %>

Now, if the incoming data doesn’t satisfy your rules, the form will be re-rendered, displaying appropriate messages.

Client-side validation

It gets a bit more complicated if you also want client-side validation. You could use xVal (I’m not sure whether it would be easier or harder), but I want to get better acquainted with ASP.NET MVC 2’s built-in client-side validation feature, so I’m going to use that.

I don’t even know if there’s an officially recommended way of doing ASP.NET MVC 2 client-side validation when you’re dynamically adding and removing form elements, but I’ll show you a technique I found that will do it. Be warned: this is rather hacky. I’d be interested to hear if anyone can suggest a better way.

First, let’s set up client-side validation in the normal way. Enable client-side validation on your form by calling Html.EnableClientValidation():

<h2>Gift List</h2>
What do you want for your birthday?
 
<% Html.EnableClientValidation(); %>
<% using(Html.BeginForm()) { %>
    (rest as before)
<% } %>

Now, as long as you’ve already referenced MicrosoftAjax.js and MicrosoftMvcValidation.js, you can run the app and you’ll immediately get working client-side validation! But hang on a minute… it only works for the elements that are present when the form is first rendered, *not* the elements added when the user clicks “Add another…”.

We need a way to capture the extra validation rules added each time the user adds a new row and somehow attach them to the form. One possible approach is to create a new type of custom view result that registers the validators associated with any partial that is renders, and have it emit some JavaScript to attach those validators to the form.

Here’s a possible implementation. Don’t worry if you don’t understand it.

public class AjaxViewResult : ViewResult
{
    public string UpdateValidationForFormId { get; set; }
 
    public AjaxViewResult(string viewName, object model)
    {
        ViewName = viewName;
        ViewData = new ViewDataDictionary { Model = model };
    }
 
    public override void ExecuteResult(ControllerContext context)
    {
        var result = base.FindView(context);
        var viewContext = new ViewContext(context, result.View, ViewData, TempData, context.HttpContext.Response.Output);
 
        BeginCapturingValidation(viewContext);
        base.ExecuteResult(context);
        EndCapturingValidation(viewContext);
 
        result.ViewEngine.ReleaseView(context, result.View);
    }
 
    private void BeginCapturingValidation(ViewContext viewContext)
    {
        if (string.IsNullOrEmpty(UpdateValidationForFormId))
            return;
        viewContext.ClientValidationEnabled = true;
        viewContext.FormContext = new FormContext { FormId = UpdateValidationForFormId };
    }
 
    private void EndCapturingValidation(ViewContext viewContext)
    {
        if (!viewContext.ClientValidationEnabled)
            return;
        viewContext.OutputClientValidation();
        viewContext.Writer.WriteLine("<script type=\"text/javascript\">Sys.Mvc.FormContext._Application_Load()</script>");
    }
}

Now, we can change the BlankEditorRow() action method to render its partial using this custom view result.

public ViewResult BlankEditorRow(string formId)
{
    return new AjaxViewResult("GiftEditorRow", new Gift()) { UpdateValidationForFormId = formId };
}

You’ll notice that BlankEditorRow() now needs to be told which form it should attach the new validators to. You’ll have to update the link to BlankEditorRow to add this information to the query string.

<%= Html.ActionLink("Add another...", "BlankEditorRow", new { ViewContext.FormContext.FormId }, new { id = "addItem" }) %>

Et voila! Each time the user appends a new row, its validators will magically be associated with the form.

The problem with removing fields

If you proceed with this approach, you’ll soon discover a further flaw. Even if the user removes fields from the form, any validators associated with those fields will still be lurking.  If a field is displaying a “required” error message, and then the user deletes the containing row, it will become impossible to submit the form because the field is still required, except now there is nowhere to enter any data for it. Whoops!

Again, I don’t know if there’s a recommended way to deal with this, but one possibility is to edit the MicrosoftMvcValidation.debug.js script a little. Let’s update the logic slightly so that, if a validator is associated with fields that no longer exist, the validator should no longer apply.

Find the function called “Sys_Mvc_FieldContext$validate”, and right at the top, add the following:

// [Added] Permanently disable this validator if its associated elements are no longer in the document
for (var j = 0; j < this.elements.length; j++) {
    if (!Sys.Mvc.FormContext._isElementInHierarchy(document.body, this.elements[j])) {
        this.validations = [];
        break;
    }
}

Now, assuming you’re referencing the file you just edited (MicrosoftMvcValidation.debug.js, rather than MicrosoftMvcValidation.js), you should get the desired change in behaviour. Deleting a row in the editor now kills its associated validation rules properly, so they don’t rise from the grave and block form submissions like invisible validation zombies.

Summary

Once you’ve got the AjaxViewResult class, it doesn’t take that much work to enable client-side validation on dynamically changing forms. Maybe there’s a better and less hacky way though… Anybody got any suggestions?

• Download the completed demo project (78kb)

A while back I posted about a way of editing a list of items where the user can add or remove as many items as they want. Tim Scott later provided some helpers to make the code neater. Now, I find myself making use of this technique so often that I thought it would be worthwhile providing an update to show how you can do it even more easily with ASP.NET MVC 2 because of its strongly-typed and templated input helpers.

Download the demo project or read on for details.

Getting Started

For this example I’m going to go with the same theme as last time and build a gift list editor. Our model object can simply be the following:

public class Gift
{
    public string Name { get; set; }
    public double Price { get; set; }
}

Displaying the Initial UI

To display the initial data entry screen, add an action method that renders a view and passes some initial collection of Gift instances.

public ActionResult Index()
{
    var initialData = new[] {
        new Gift { Name = "Tall Hat", Price = 39.95 },
        new Gift { Name = "Long Cloak", Price = 120.00 },
    };
    return View(initialData);
}

Next, add a view for this action, and make it strongly-typed with a model class of IEnumerable<Gift>. We’ll create an HTML form, and for each gift in the collection, we’ll render a partial to display an editor for that gift.

<h2>Gift List</h2>
What do you want for your birthday?
 
<% using(Html.BeginForm()) { %>
    <div id="editorRows">
        <% foreach (var item in Model)
            Html.RenderPartial("GiftEditorRow", item);
        %>
    </div>
 
    <input type="submit" value="Finished" />
<% } %>

I know it would be possible to use ASP.NET MVC 2’s Html.EditorFor() or Html.EditorForModel() helpers, but later on we’re going to need more control over the HTML field ID prefixes so in this example it turns out to be easier just to use Html.RenderPartial().

Next, to display the editor for each gift in the sequence, add a new partial view at /Views/controllerName/GiftEditorRow.ascx, strongly-typed with a model class of Gift, containing:

<% using(Html.BeginCollectionItem("gifts")) { %>
    <div class="editorRow">
        Item: <%= Html.TextBoxFor(x => x.Name) %> 
        Value: $<%= Html.TextBoxFor(x => x.Price, new { size = 4 }) %> 
    </div>        
<% } %>

Here’s where we get to start using ASP.NET MVC 2 features and make things slightly easier than before. Notice that I’m using strongly-typed input helpers (Html.TextBoxFor()) to avoid the need to build element IDs manually. These helpers are smart enough to detect the “template context” in which they are being rendered, and use any field ID prefix associated with that template context.

You might also be wondering what Html.BeginCollectionItem() is. It’s a HTML helper I made that you can use when rendering a sequence of items that should later be model bound to a single collection. You give it some name for your collection, and it opens a new template context for that collection name, plus a random unique field ID prefix. It also automatically renders a hidden field, which in this case is called gifts.index, populating it with that unique ID, so when you later model bind to a list, ASP.NET MVC 2 will know that all the fields in this context should be associated with a single .NET object.

And now, if you visit the Index() action, you should see the editor  as shown below. (I’ve added some CSS styles, obviously.)

Receiving the Form Post

To receive the data posted by the user, add a new action method as follows.

[HttpPost]
public ActionResult Index(IEnumerable<Gift> gifts)
{
    // To do: do whatever you want with the data
}

How easy is that? Because Html.BeginCollectionItem() observes ASP.NET MVC 2 model binding conventions, you can receive all the items in the list without having to do anything funky.

You could also achieve the same with less code by using the built-in Html.EditorFor() or Html.EditorForModel() helpers, but because these use a different indexing convention (an ascending sequence, not a set of random unique keys), things would get more difficult when you try to add or remove items dynamically.

Dynamically Adding Items

If the user wants to add another item, they’ll need something to click to say so. Let’s add an “Add another…” link. Add the following to the main view, just before the “Finished” button.

<%= Html.ActionLink("Add another...", "BlankEditorRow", null, new { id = "addItem" }) %>

This is a link to an action called BlankEditorRow which doesn’t exist yet. The idea is that the BlankEditorRow action will return the HTML markup for a new blank row. We can fetch this markup via Ajax and dynamically append it into the page.

To make this Ajax call and append the result into the page, make sure you’ve got jQuery referenced, and create a click handler similar to this:

$("#addItem").click(function() {
    $.ajax({
        url: this.href,
        cache: false,
        success: function(html) { $("#editorRows").append(html); }
    });
    return false;
});

Note that it’s very important to tell jQuery to tell the browser not to re-use cached responses, otherwise those unique IDs won’t always be so unique… And before we forget, we’ll need to put the BlankEditorRow action in place:

public ViewResult BlankEditorRow()
{
    return View("GiftEditorRow", new Gift());
}

As you can see, it simply renders the same editor partial, passing a blank Gift object to represent the initial state. I’m very pleased that you can re-use the same editor partial in this way – it means there’s no duplication of view markup and we can stay totally DRY.

And that, in fact, is all you have to do – each time the user clicks “Add another…”, the client-side code will inject a new blank row into the editor. Because each row has its own unique ID, when the user later posts the form, all the data will be model bound into a single IEnumerable<Gift>.

Dynamically Removing Items

Removing items is easier, because all you have to do is remove the corresponding DOM elements from the HTML document. If the elements are gone, their contents won’t be posted to the server, so they won’t be present in the IEnumerable<Gift> that your action receives.

Add a “delete” link to the GiftEditorRow.ascx partial:

<a href="#" class="deleteRow">delete</a>

This needs to go inside the DIV with class “editorRow”, so you can handle clicks on it as follows:

$("a.deleteRow").live("click", function() {
    $(this).parents("div.editorRow:first").remove();
    return false;
});

Notice that this code uses jQuery’s “live” function, which tells it to apply the click handler not only to the elements that exist when the page is first loaded, but also to any matching elements that are dynamically added later.

You’ve now got a working editor with “add” and “delete” functionality.

Summary

I hope you can see that editing variable-length lists can be very easy. Other than the reusable Html.BeginCollectionItem() helper, I’ve just shown you every line of code needed for this particular strategy, and in total it’s just 36 lines (including the model, action methods, views, and JavaScript, but excluding lines that are purely whitespace or braces).

Download the full demo project

But what about validation?

Yes, I haven’t forgotten about that! You can already do your server-side validation any way you want – by default the model binder will respect any rules associated with your model.

In the next post, I’ll show how you can integrate this list editing strategy with ASP.NET MVC 2’s client-side validation feature.