ASP.NET MVC Tip #3: Client-side form validation made easy – Part 1

Client-side form validation has become a de-facto standard for modern web applications. However, replicating server-side validation rules on the client side can be a tedious and error-prone process.

In addition, there are some validation rules which cannot be checked completely on the client side, for example because the validation depends on information stored in the server database. For those rules you need to implement remote client-side form validation.

The xVal framework is great for automatic generation of client-side validation code for some of your server-side validation rules, but it does not support remote client-side validation.

This article shows a fully generic way to implement remote client-side form validation so that

• Validation rules remain solely in your ASP.NET MVC model
• You write each validation rule just once, and only in easily testable C# code. There is no JavaScript or other client-side counterpart .
• There is no need to branch or otherwise modify xVal or jquery.validate
• All you have to do for each new remote form validation rule is to derive from the base class shown in this article.

I’ll describe how to implement this in detail. I’ve also uploaded a demo project showing how this works in action.

A brief example

Let’s assume you are implementing a website signup form. For the sake of simplicity, lets limit the form to asking for an e-mail address and a password.

Figure 1 – Example signup form

You want to implement the signup form with both client and server side validation. For the e-mail field, let’s enforce the following validation rules:

1. Email address is not missing
2. Email address looks valid
3. There is no other user with the same e-mail address in your database.

Rules 1 and 2 can easily be checked on the client side. However, rule 3 can only be done with remote validation: Your client-side validation script needs to connect to your web server and ask if the e-mail address is already taken.

In our example, the only user already in the databse shall be adrian@lobstersoft.com. As soon as someone enters this e-mail address in the form and hits tab, return, or the Create button, an error message should appear before the form has even been posted:

Figure 2 – Error messages should appear before the form has even been posted

Listing 1 shows the entire validation logic necessary for both client and server side validation:

Listing 1 – Signup form client- and server-side validation rules

using System.ComponentModel.DataAnnotations;

namespace RemoteValidation.Models
{
    public class User
    {
        [Required(ErrorMessage = "E-mail address is missing.")]
        [RegularExpression(EmailRegEx, ErrorMessage = "Invalid e-mail address.")]
        [IsNew(ErrorMessage = "Someone has already signed up with this e-mail address.")]
        public string Email { get; set; }

        [Required(ErrorMessage = "Password is missing.")]
        public string Password { get; set; }

        public class IsNewAttribute : RemotePropertyValidator
        {
            protected override bool PropertyValid(object value)
            {
                return (string)value != "adrian@lobstersoft.com";
            }
        }

        private const string EmailRegEx = @"^(([^<>()[\]\\.,;:\s@\""]+"
                                  + @"(\.[^<>()[\]\\.,;:\s@\""]+)*)|(\"".+\""))@"
                                  + @"((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"
                                  + @"\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+"
                                  + @"[a-zA-Z]{2,}))$";
    }
}

The SignUp action methods should also be easy to implement since the controller does not need to know anything about our validation rules.

Listing 2 – Signup form action methods

         //
        // GET: /Users/SignUp
        public ActionResult SignUp()
        {
            return View(new User());
        }

        //
        // POST: /Users/SignUp
        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult SignUp(User model)
        {
            if (!ModelState.IsValid)
            {
                return View(model);
            }

            //Add User to database and start spamming daemon here

            return RedirectToAction("SignUpComplete");
        }

Lastly, here’s how the view above is implemented.

Listing 3 – Signup form view implementation

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

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    SignUp
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        SignUp</h2>
    <%= Html.ValidationSummary("SignUp was unsuccessful. Please correct the errors and try again.") %>
    <% using (Html.BeginForm())
       {%>
    <fieldset>
        <legend>Fields</legend>
        <p>
            <label for="Email">
                Enter your e-mail address:</label>
            <%= Html.TextBox("Email")%>
            <%= Html.ValidationMessage("Email", "*")%>
        </p>
        <p>
            <label for="Password">
                Enter a password:</label>
            <%= Html.Password("Password")%>
            <%= Html.ValidationMessage("Password", "*")%>
        </p>
        <p>
            Hint: To see that remote validation works, try signing up as "adrian@lobstersoft.com".
        </p>
        <p>
            <input type="submit" value="Create" />
        </p>
    </fieldset>
    <% } %>

    <%= Html.ClientSideValidation<RemoteValidation.Models.User>()%>
</asp:Content>
[/sourcecode ]


Note that the View does not contain any JavaScript or other means to specify client-side validation rules. Everything is done transparently and automatically behind the scenes.


<h2>Prerequisites</h2>

In order for this to work, you need to set up a few things first:
<ol><li>
Data Annotation validation attributes for server-side validation. IMO this is the best way to handle server-side validation anyway, even if you are not using client-side validation at all.

Brad Wilson has written a great <a href="http://bradwilson.typepad.com/blog/2009/04/dataannotations-and-aspnet-mvc.html">blog article</a> on how to use DataAnnotations in ASP.NET MVC.

Note that there is a bug in DataAnnotationModelBinder which might lead to NullReferenceExceptions when using custom ViewModels. This does not become apparent in our demo project, but if you should encounter this problem, you can find a fix in <a href="http://stackoverflow.com/questions/820468/how-does-dataannotationsmodelbinder-work-with-custom-viewmodels">this StackOverflow posting</a>.
</li><li>
Download and reference <a href="http://bassistance.de/jquery-plugins/jquery-plugin-validation/">jquery.validate </a>in your Master Page.
</li><li>
Download and reference <a href="http://xval.codeplex.com/">xVal</a>  version 0.8 or later in your project. xVal is a great framework for easy implementation of client-side validation in ASP.NET MVC. It transforms standard server-side validation rules into client-side validation rules recognized by jquery.validate.

Steve Sanderson describes how to set it up and use in <a href="http://blog.codeville.net/2009/01/10/xval-a-validation-framework-for-aspnet-mvc/">this blog article</a>.
</li></ol>
Once you get this far, you can implement rules 1 and 2 from our example. You could also implement rule 3, although you'd have to derive it from System.ComponentModel.DataAnnotations.ValidationAttribute, so there would't be any client-side validation for that.

<h2>Implementing generic client-side Remote Validation</h2>

While rules 1 and 2 are automagically enforced by xVal on both the client and server side, rule 3 is only checked when the user posts the form. That's because xVal does not know what to do with our custom rule. It just looks for standard validation rules like Required, StringLength or RegularExpression and ignores everything else.

Enforcing rule 3 on the client side as well without incurring any additional effort is where the technique I would like to present comes into play.

The first step is not to derive your custom validation rule from ValidationAttribute, but from the RemotePropertyValidator class I implemented. This is already depicted in Listing 1 above.

RemotePropertyValidator is in turn derived from ValidationAttribute, but it also implements xVal's ICustomRule interface. This allows it to specify a JavaScript function that should be executed in order to check if the given property is valid on the client side.

RemotePropertyValidator tells xVal to execute the JavaScript function "RemotePropertyValidation". The parameters for this function should be the type of your derived custom validator and the Error message you specified:

<strong>Listing 4 - RemotePropertyValidation class</strong>

   public abstract class RemotePropertyValidator : ValidationAttribute, ICustomRule
    {
        public CustomRule ToCustomRule()
        {
            return new CustomRule(
                &quot;RemotePropertyValidation&quot;, // JavaScript function name
                new
                    {
                        validator = ToString(),
                        errorMessage = base.ErrorMessage,
                    }, // Params for JavaScript function

                base.ErrorMessage
                );
        }
    }

You might be wondering why I am checking for empty strings / null in Listing 4. That’s because of differences between how xVal / jquery.validate work on the client side and how the DataAnnotationsModelRunner is implemented on the server side: While it is possible to implicitly implement a Required validator by deriving from ValidationAttribute on the server side, it is not possible to do this with ICustomRule descendents on the client. So I am checking for empty strings / null to avoid inconsistent behaviour.

The ClientSideRegEx property can be set to a regular expression that will be executed on the client before the remote validation is done. You can use it to avoid unnecessary calls to your RemoteValidation controller.

Now, when the user starts typing something in the e-mail field, the browser will execute the JavaScript function “RemotePropertyValidation”. Note that this function will receive your derived server-side validator’s object type and your validator’s error message as parameters.

Next, we need to implement a generic RemotePropertyValidation function. In this function we can create a “remote” validation rule as supported by jquery.validate and attach it to the Email e-mail input field’s rules collection:

Listing 5 – Generic client-side remote validation function

function RemotePropertyValidation(value, element, params) {
    var wrappedElement = $(element);
    if (wrappedElement.rules()["remote"] === undefined) {
        //add optional regEx validator to minimize ajax requests
        if (params.regEx !== null && wrappedElement.rules()["xVal_regex"] === undefined) {
            wrappedElement.rules("add", {
                xVal_regex: [params.regEx],
                messages: {
                    xVal_regex: params.errorMessage
                }
            });
        }
        var remoteRule =
        //add a new remote validation rule
        wrappedElement.rules("add", {
            remote: {
                url: "/RemoteValidation/Property",
                data: {
                    value: new CreateInputValueAccessor(wrappedElement.attr("name")),
                    validator: params.validator
                }
            },
            messages: {
                remote: params.errorMessage
            }
        });

        //validate element again to trigger the new rule(s)
        $("form").validate().element(wrappedElement);
    }
    return true;
}

function CreateInputValueAccessor(inputName) {
    return function() {
        return $("[name=" + inputName + "]").val();
    };
}

The RemotePropertyValidation () function should be referenced in your Master page. Now the first time a user enters something in the Email field , jquery.validate will first validate it using the Required and the Regex rule. If both rules are satisfied, it will check if the e-mail address is already taken with the validation rule that RemotePropertyValidation() inserted on the fly. This will fetch the following URL and parse the JSON reply as validation result.:

http:///RemoteValidation/Property?value=&validator=RemoteValidtion.Models.User.IsNew

Now we just need to implement a RemoteValidation that construct an appropriate validator object (note that this is provided in “validator” request parameter), let it validate the user input and return the validation result as JSON:

Listing 6 – RemoteValidation controller

using System;
using System.Reflection;
using System.Web.Mvc;
using RemoteValidation.Models;

namespace RemoteValidation.Controllers
{
    public class RemoteValidationController : Controller
    {
        //
        // GET: /RemoteValidation/Property
        public JsonResult Property()
        {
            Type validatorType = Type.GetType(Request["validator"], true);
            var validator = (RemotePropertyValidator) Activator.CreateInstance(validatorType);
            return Json(validator.IsValid(Request["value"]));
        }
    }
}

And that’s it! Now that you have the JavaScript RemotePropertyValidation function and the remote validation controller in place, all you need to do for new custom validation rules is to derive them from RemotePropertyValidator. This ensures that your validation rules are are automatically enforced on both the server and the client.

For example, all you’d need to implement for server AND remote client-side validation of password strength is this:

Listing 7 – Complete implementation of an additional client- and server-side Validator

 public class IsSafePasswordAttribute : RemotePropertyValidator
        {

            public IsSafePasswordAttribute()
            {
                //perform some simple password strength check with a regular expression
                //on the client side first
                ClientSideRegEx = ".{8,20}";
            }

            protected override bool PropertyValid(object value)
            {
                //Insert more elaborate server-side / remote client side password checking
                // logic and return result here...
            }
        }

Caveats

There are a few things you should keep in mind when using this technique:

• You can’t implicitly implement a Required validator using this technique, so if a property is not optional, you must always decorate it with a Required validator apart from of your own RemotePropertyValidator descendant. It wouldn’t really make sense to implement a Required validator this way anyway. Please see the Implementation section above if you are interested in the reason for this.
• You can only apply one remote validation rule per form field. This is a limitation of jquery.validate, and it makes sense not to have more than one remote validation rule anyway since you want to minimize the amount of server postbacks as much as possible. If you need to remotely check two different rules on the same property, you can always write a new rule which incorporates both checks, so the only problem is finding an error message that fits both validation rules.
• This approach only works for Validation Attributes applied to properties, not to entire business entities. I’ll discuss a similar approach for validating entire business entities in the second part of this article.

Download the finished demo project

Summary

Now you know how to implement remote client-side validation without writing any custom JavaScript code. I discussed how to implement all validation rules, even those that can only be checked on the server, on both the client AND server side in C# code only. I showed how you can do this without any additional effort when implementing new rules.

The only real limitation is that the business rule can check only a single property, not an entire business entity. Stay tuned for the second part of this article, where I’ll discuss how to circumvent this limitation in a similarly easy way.

Edit: The second part of this article has already been posted here.