• Part 1: Just get it to work
• Part 1.1: The other forms
• Part 2: Clean up and conventions (coming soon)
• Part 3: Summary and overview (coming soon(ish))

After I finished my last post, Modal Forms with ASP.NET MVC 3 and jQuery – Part 1: Just get it to work, I updated all the other forms so they were also modal popups.

View GitHub Commit

Now that all the forms have been turned into modal forms, you should notice that there is a lot of repeated code.

Especially note the repetition in the javascript (here and here), this is where most of the clean up will occur.

• Part 1: Just get it to work
• Part 1.1: The other forms
• Part 2: Clean up and conventions (coming soon)
• Part 3: Summary and overview (coming soon(ish))

As a ASP.NET MVC developer I find that all my forms tend to follow a very similar pattern. Put simply it starts with a GET, validation occurs on the client, POST with model binding, additional validation on the server and finally I either re-display the form OR redirect to another action with a success message.

To add another twist, I’ve been using jQuery UI modal dialogs to display a number of the smaller forms, e.g. log on, registration, change password, etc.

With all of this going on, I’ve created a nice and easy way to do this using conventions so any modal forms I create require very little effort to setup. And because I’m such a nice guy, I’m going to share it with all of you!

For the purpose of this blog series I started with new ASP.NET MVC 3 Web Application because it conveniently already has log in, register and change password forms that can easily be turned into modal forms.

I’ll be using GitHub through the whole series, so you can follow along and download the code to run on your local machine. I’ll also be linking to my specific commits as an easy way to show you what’s going on.

This first post will simply get the modal forms to work. I’m not going to lie, it gets ugly… but just know that the follow-up blog posts will clean it all up, so just hang in there.

First things first

• Move all the javascript to the bottom of the page, it’s just how I roll (for good reason)
• Move the jquery.validate.min.js & jquery.validate.unobtrusive.min.js references to the _Layout.cshtml page because they’ll be needed on most pages.

View GitHub Commit

Now lets get a modal form popping up. We’ll start with the log on form.

To do:

• Reference the jQueryUI JS & CSS
• Give the log on link an id so we can reference it in our javascript
• Make the log on action return a partial view and clean out any unwanted html from the view
• Create a new javascript file to do our bidding

View GitHub Commit

Result showing the new modal form:

Looking at the GitHub commit, pay particular attention to the new ModalForms.Init.js file, the following things are happening:

• A new click handler is attached to the log on link
• A div, named ‘dialogDiv’, is created and attached to the body of the page
• We use the url from the log on link to make a ajax request and populate the dialogDiv through a jQuery .load() call
• When the dialogDiv is populated we turn it into a jQueryUI modal dialog
• Remove the dialogDiv from the dom when the modal is closed

This is all good and we’re getting somewhere, but the functionally is up the boohai, so lets get things working a bit better.

So whats wrong? Well, to start with the form has lost it’s client side validation. Luckily because we’re using the jQuery validation & unobtrusive validation, fixing the client side validation is simple.

By default the unobtrusive validation library parses the page once it loads looking for data- attributes and creates jQuery validation rules for them, but because our modal form is loaded after the original page is loaded, it wasn’t parsed. The log on form still has all the required data- attributes needed for unobtrusive validation, so all we need to do is get the unobtrusive validation module to parse this new form.

View GitHub Commit

Told you it was simple.

Result showing client validation working agian:

It’s probably at this point that I should mention that I’m not going to mess around with the looks of anything too much, just pretend that things look pretty.

The other major thing that is wrong at this point, is that the modal form is still doing a traditional POST to the server. We want to change this so that it’s all done through AJAX.

To do:

• Create a new BaseController that contains a couple of shorthand JsonResults for success and failure
• Alter the LogOn POST action to return the new JsonResults
• Remove the form’s default submit button
• Create a jQueryUI dialog button that submits the form through an AJAX call
• Create a cancel button.
• NOTE: I also visited /Account/Register to setup an account to test logging on (TenSpeed:password)

View GitHub Commit

Result showing POSTs with both invalid and valid credentials:

And after the successful log on:

Sweet! Now we’re getting somewhere!

What’s missing? Well, when there are errors on the server, we need to send them back to the client and then display them.

We’ll do this in two parts because it’s a little more complicated than what we’ve done before. First up, we’ll get the server side code to send us some errors back, that part is easy.

To do:

• Create a new ErrorDictionary class to hold the errors that get sent to the client
• Add an extension method for ModelStateDictionary to throw all the ModelState errors into an ErrorDictionary
• Lastly we need to send the ErrorDictionary back to the client

View GitHub Commit

Result showing errors in the response:

Nothing too major there, it’s pretty straight forward. Displaying them on the other hand is easier said than done.

I like my validation errors in a validation summary div, so that’s how I’m going to go about this… again, it’s just how I roll. So we have to make something that will play nicely with the existing client side validation and something that we can manipulate when we get our errors from the server.

To do:

• Remove the validation messages from beside the inputs on the log on form
• Create validation summary container on the client that the unobtrusive validation will use and that we can manipulate ourselves
• Display the errors from the server

View GitHub Commit

NOTE: I really really really wanted to put the validationSummary stuff inside the ModalForms.Init.js file to make it even more monstrous but I just couldn’t bring myself to do it ;-)

Result with standard client side validation:

And displaying errors from the server:

The big update here was the addition of the ModalForms.ValidationSummary.js file, so lets have a look at that in a bit more depth by going through the 5 basic functions in the validationSummary class.

• setUp – this, surprisingly, sets up the validationSummary by either finding an existing one or creating a new one. It takes a jQuery object as a parameter, this object is where the validationSummary should be found or appended to… in most cases it will be the form.
• createNew – this will generate the html for a new validationSummary. You should note that the html it generates has a ‘data-valmsg-summary’ attribute set to true – this will enable the client side validation to use it.
• addErrors – this takes a bunch of errors and puts them into the validationSummary.
• addError – this adds a single error to the validationSummary.
• clearErrors – this clears all the errors from the validationSummary and resets everything back to a valid state.

And there we have it, a fully working modal log on form.

Now I know that ModalForms.Init.js file aint got no alibi, but we’re going to take care of that in Part 2 – Clean up and conventions.

Thanks and stay tuned!

Anyway, here’s the code I’m using that is working a treat.

namespace PageDesigners.Library.ValidationAttributes
{
    public class EmailAttribute : RegularExpressionAttribute, IClientValidatable
    {
        public EmailAttribute()
            : base(@"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}" +
                   @"\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\" +
                   @".)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$")
        {
        }

        public IEnumerable GetClientValidationRules(ModelMetadata metadata, ControllerContext context)
        {
            var errorMessage = FormatErrorMessage(metadata.GetDisplayName());

            yield return new EmailValidationRule(errorMessage);
        }
    }

    public class EmailValidationRule : ModelClientValidationRule
    {
        public EmailValidationRule(string errorMessage)
        {
            ErrorMessage = errorMessage;
            ValidationType = "email";
        }
    }
}

Then simply use it like so

public class SignUpForm
{
    //Blah

    [DisplayName("Your email")]
    [Required(ErrorMessage = "{0} is required.")]
    [Email(ErrorMessage = "{0} appears to be invalid.")]
    public string EmailAddress { get; set; }

    //Blah
}

Enjoy.

There are a few reasons I find the decoupling a nice clean solution. The main two reasons are:

• rendering a form on multiple views
• getting individual forms using ajax for modal windows

Let’s see how it works. Take a simple register page like the following (based on the default ASP.NET MVC project).

Register.aspx

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<MvcApplication1.Models.RegisterViewModel>" %>

<asp:Content ID="registerContent" ContentPlaceHolderID="MainContent" runat="server">

    <h2>Create a New Account</h2>

    <p>
        Use the form below to create a new account.
    </p>

    <% Html.RenderAction("RegisterForm"); %>
</asp:Content>

RegisterForm.ascx

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<MvcApplication1.Models.RegisterFormModel>" %>

<% using (Html.BeginForm()) { %>
    <%: Html.ValidationSummary(true, "Account creation was unsuccessful. Please correct the errors and try again.") %>
    <div>
        <fieldset>
            <legend>Account Information</legend>

            <div class="editor-label">
                <%: Html.LabelFor(m => m.UserName) %>
            </div>
            <div class="editor-field">
                <%: Html.TextBoxFor(m => m.UserName) %>
                <%: Html.ValidationMessageFor(m => m.UserName) %>
            </div>

            <!-- Blah blah -->

            <div class="editor-label">
                <%: Html.LabelFor(m => m.ConfirmPassword) %>
            </div>
            <div class="editor-field">
                <%: Html.PasswordFor(m => m.ConfirmPassword) %>
                <%: Html.ValidationMessageFor(m => m.ConfirmPassword) %>
            </div>

            <p>
                <input type="submit" value="Register" />
            </p>
        </fieldset>
    </div>
<% } %

AccountController.cs

public ActionResult Register()
{
    var viewModel = AccountService.GetRegisterViewModel(MembershipService);
    return View(viewModel);
}

[HttpPost]
public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        //registration code
    }

    // If we got this far, something failed, redisplay form
    var viewModel = AccountService.GetRegisterViewModel(MembershipService);
    return View(viewModel);
}

public PartialViewResult RegisterForm()
{
    var formModel = AccountService.GetRegisterFormModel();
    return PartialView(formModel);
}

Got my drift? Good.

But this approach has a problem… when you call .RenderAction a new controller is spun up, so you loose all the previous controller and view context that was setup – this is especially important for forms because you lose all the modelstate errors.

Losing modelstate errors is no good at all because the partial view can’t render any of the errors.

Fix

Conveniently, the ActionExecutingContext contains a property ‘ParentActionViewContext’ where we can access the previous modelstate we need.

So all we need to do is create a custom action attribute that populates the partial actions modelstate like so:

KeepParentModelErrors.cs

public class KeepParentModelErrors : FilterAttribute, IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext filterContext)
    {
        if (filterContext.ParentActionViewContext == null)
            return;

        var parentContext = filterContext.ParentActionViewContext;

        var modelState = filterContext.Controller.ViewData.ModelState;
        foreach (var modelStateItem in parentContext.ViewData.ModelState)
        {
            if (modelState.ContainsKey(modelStateItem.Key))
            {
                foreach (var error in modelStateItem.Value.Errors)
                {
                    if (!modelState[modelStateItem.Key].Errors.Contains(error))
                        modelState[modelStateItem.Key].Errors.Add(error);
                }
            }
            else
            {
                filterContext.Controller.ViewData.ModelState.Add(modelStateItem);
            }
        }
    }

    public void OnActionExecuted(ActionExecutedContext filterContext)
    {
        //Nothing to do here
    }
}

Thoughts?

After a bit more investigation I found it had to do with my culture… well, rather it had to do with the  GET request binding my date (formatted as ‘dd/mm/yyyy’) using the backwards American date format of ‘mm/dd/yyyy’ (flame on).

It was late at night at the time, so I quickly whipped up a very basic ASP.NET MVC application to reproduce the interesting behaviour I was experiencing and fired it off to Phil Haack – which in hindsight wasn’t probably the best route to take, should’ve followed some sort of procedure and posted it to codeplex project’s issue tracker instead of bothering Phil.

Anyway… after a good nights sleep, a good day at work under my belt and no reply from Phil (obviously a busy man and bigger things to worry about), I decided to have a gander at the issue myself.

After a short time of debuging into the ASP.NET MVC 2 Beta source code, I managed to find the culprit. Surprisingly the issue resided in the QueryStringValueProvider class – I know, who would’ve guessed?!

What I found is the following in all its undisguised glory:

// QueryString should use the invariant culture since it's part of the URL, and the URL should be
// interpreted in a uniform fashion regardless of the origin of a particular request.
protected override CultureInfo GetCulture(ControllerContext controllerContext) {
    return CultureInfo.InvariantCulture;
}

My first thought was ‘hang on, so this weird behaviour is actually intentional? WTF were they thinking?!?’. Then, naturally, images of a CultureAwareQueryStringValueProvider swirlled around my head – easy ‘fix’ I thought. But as my testosterone levels started to drop back to normal, I realised that someone smarter than me has obviously made a very conscience decision to make it culture unaware…

So why is it culture unaware?

Well, if you think about it, a URL is a pointer to a specific resource. So if the url is culture aware, that same URL could point to different resources.

E.g. say there was a URL like:

‘http://www.temp.com/events?from=01/01/2010&to=01/03/2010&page=3’

If it was culture aware, my culture would expect it to show the 3rd page of events between 1st Jan 2010 & 1st March 2010 BUT someone else’s inferior culture (flame stoke) might expect it to show the 3rd page of events between 1st Jan 2010 & 3rd Jan 2010.

Making sense now? Good.

So what are my options to fix this? Well, as I see it, there are 3 obvious solutions.

Option 1: Use a POST request instead of a GET request. This really isn’t an option, in my situation I really need it to be a GET request.

Option 2: Create a custom binding to make the querystring culture aware. This really isn’t an option because as I outlined above, URLs shouldn’t be culture aware.

Option 3: Change the date format in the querystring. I.e. use the ‘yyyy/mm/dd’ format so that all cultures will understand and interpret the URL the same¹. This is really the only option for me and I’m relatively happy with it… from a technical perspective it’s super but from a usability perspective (e.g. users having to enter dates in that format), it may not be the best.

Any other ideas dear reader?

EDIT: Got a reply from Phil and he basically backed up my understanding of the situation and gave his take on some solutions similar to those outlined above. Cheers Phil! :-)

¹If someone tells me that some culture recognises the date format ‘yyyy/dd/mm’ I’ll probably cry. Seriously.

I’m guessing that (like myself) a lot of people out there are using ORM’s to generate their models. Yeah? Thought so. Anyway, looking at that previous sentence, the key word is *generate*. You see, if you put property attributes in these generated files, they’re just going to be wiped each time you make a db schema change – far from ideal! ;-)

So where do you put these attributes?

Nope, you can’t put them in a partial class because C# and VB.NET don’t allow you to add attributes to properties defined in another partial class.

Enter the Buddy Class!

The Gu touched on buddy classes in his aforelinked¹ post, but didn’t go into them in any detail – so I’m going to try and fill that void with this post.

Say we have a ‘Customer’ table (similar to The Gu’s example) in our database and our orm generates a class like so:

public partial class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
    public string Email { get; set; }
    public string Country { get; set; }
}

Before we go any further (if you haven’t already) you should add a reference to System.ComponentModel.DataAnnotations.dll to your project – you’re gonna need it.

Next we create a partial class for the generated class and also create it’s buddy class.

The best way to explain this is with code, so here you go:

[MetadataType(typeof(Customer_Metadata))]
public partial class Customer
{
    //Custom model stuff here
}

public class Customer_Metadata
{
    [DisplayName("First name")]
    [Required(ErrorMessage = "First name is required")]
    public string FirstName { get; set; }

    [DisplayName("Last name")]
    [Required(ErrorMessage = "Last name is required")]
    public string LastName { get; set; }

    [Range(1, 120, ErrorMessage = "Invalid Age")]
    public int Age { get; set; }

    [Required(ErrorMessage = "Email is required")]
    [RegularExpression(@"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$")]
    public string Email { get; set; }

    [Required(ErrorMessage = "Country is required")]
    [UIHint("CountryDropDown")]
    public string Country { get; set; }
}

Savvy? Good, because that’s really all there is to it! ;-)

¹aforelinked – new word? © Charles Vallance 2009

EDIT: Making the buddy class a private inner class

As outlined below by Tyrone and Steve, it’s probably best practice to have the buddy class as a private inner class.

E.g.

[MetadataType(typeof(Customer.Metadata))]
public partial class Customer
{
    //Custom model stuff here

    private sealed class Metadata
    {
        [DisplayName("First name")]
        [Required(ErrorMessage = "First name is required")]
        public string FirstName { get; set; }

        [DisplayName("Last name")]
        [Required(ErrorMessage = "Last name is required")]
        public string LastName { get; set; }

        [Range(1, 120, ErrorMessage = "Invalid Age")]
        public int Age { get; set; }

        [Required(ErrorMessage = "Email is required")]
        [RegularExpression(@"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$")]
        public string Email { get; set; }

        [Required(ErrorMessage = "Country is required")]
        [UIHint("CountryDropDown")]
        public string Country { get; set; }
    }
}

Each of the forms have their own separate ValidationSummary() calls to display their validation errors. But when I posted to either one of these actions and the validation failed, I quickly realised a short coming of the built in ValidationSummary() helper method… you see, it doesn’t have a clue about which form has the errors!

Confused yet? Oddly enough, so am I.

A screen shot should clear things up:

And the fail:

Making sense now? Good…

Anyway, I came up with an easy enough work around so I thought I would share it.

namespace System.Web.Mvc
{
    public static class HtmlExtensions
    {
        public static string ActionValidationSummary(this HtmlHelper html, string action)
        {
            string currentAction = html.ViewContext.RouteData.Values["action"].ToString();

            if (currentAction.ToLower() == action.ToLower())
                return html.ValidationSummary();

            return string.Empty;
        }
    }
}

I’m (basically) calling it like so:

<h2>Register</h2>

<%= Html.ActionValidationSummary("Register") %>

<form method="post" id="register-form" action="<%= Html.AttributeEncode(Url.Action("Register")) %>">

... blah ...

</form>

<h2>User Login</h2>

<%= Html.ActionValidationSummary("LogIn") %>

<form method="post" id="login-form" action="<%= Html.AttributeEncode(Url.Action("LogIn")) %>">

... blah ...

</form>

And that’s it. Enjoy.