October 2017 : Online course in ASP.NET MVC / Core. Conducted by Bipin Joshi. Read more...
Registration for October 2017 batch of ASP.NET MVC / Core online course has already started. Conducted by Bipin Joshi. Book your seat today ! Click here for more details.

Customize HTML5 Validation Messages in ASP.NET MVC

HTML5 allows you to put constraints on the data entered in form fields through several techniques. These techniques include new input types (such as email and url) and attributes such as required and pattern. When these constraints are violated the browser shows an error message callout and the form submission is cancelled. Although this default arrangement works great in many applications, at times you may want to customize the error messages and how they are displayed. This article explains how such a customization can be achieved with the help of a couple of new events and a dash of jQuery code.

Before you go ahead and customize the inbuilt validation messages, have a look at the following figure that shows how Chrome displaying validation error on an email field.

As you can see the default error message is displayed in a callout and you don't have any direct control on the look and feel of this callout. If you are developing an ASP.NET MVC application, chances are you are already using HTML helpers such as ValidationMessage() and ValidationSummary(). For the sake of consistency you may want to display HTML5 validation messages just like ASP.NET MVC helpers rather than a callout. Additionally, you may want to customize the error message text being displayed.

The above tasks can be accomplished by handling these two HTML5 events:

  • input
  • invalid

The input event is raised whenever some content is inputted in an editable control such as textbox. Instead of handling keypress or keydown the input event is a great place to put custom validation logic. The invalid event is raised for a form field if its value violates the constraints imposed on it. These constraints can be in the form of input types (for example, email), required attribute, pattern attribute or even a custom constraint imposed through JavaScript code.

Using input types or inbuilt HTML5 attributes is quite straightforward. Adding a custom constraint usually involves handing input event to perform a custom validation and then flagging the success or failure of the validation through setCustomValidity() method of HTML5. The setCustomValidity() method is also used to customize the error messages of the inbuilt validations.

The following figure shows the same email validation after customization.

Now let's see the code that makes this work.

We will do the following:

  • Put constraint on the textbox so that its value must be an email address.
  • The textbox must contain a value.
  • The email address must be lesser than 50 characters.

The first constraint can be added by setting the type attribute of the <input> element to email. The second constraint can be added by setting the required attribute on the <input> element. The third constraint can be added using input event handler. You can also add the third constraint through other techniques such as pattern attribute but we will use input event handler to illustrate its use in overall validation process. The following markup shows how a sample <form> from an ASP.NET MVC view looks like:

<form action="/home/index" method="post">
    <input type="email" id="email" required />
    <span id="shorterrormsg">*</span>
    <br /><br />
    <input type="submit" value="Submit" />
</form>
<br />
<div id="longerrormsg"></div>

The shorterrormsg <span> element is used to display the * whenever there is an error. The longerrormsg <div> element is used to display the descriptive error message.

The following code shows the input event handler of the email textbox.

$("#email").on("input", function (evt) {
    if (evt.target.value.length>50) {
        evt.target.setCustomValidity("Email too long!!!");
        $("#shorterrormsg").show();
        $("#longerrormsg").html("Email too long!!!");
    }
    else
    {
        evt.target.setCustomValidity("");
        $("#shorterrormsg").hide();
        $("#longerrormsg").html("");
    }
});

The input event handler checks the length of the text entered in the email textbox. If its length is greater than 50 characters the code calls the setCustomValidity() method on the email textbox (accessed as evt.target property). The setCustomValidity() method accepts an error message to be displayed. If the parameter to setCustomValidity() is a non-empty string the browser treats it as a validation error and also displays it using default callout. The code also shows the short error message <span> element and also adds an error message to the long error message <div> element.

The else block of the code sets the error message to an empty string indicating that there is no validation error. The <span> and <div> elements are also cleared.

The following code shows the invalid event handler of the email textbox.

$("#email").on("invalid", function (evt) {
    var reason = evt.target.validity;
    if (!reason.customError) {
        if (reason.typeMismatch) {
            evt.target.setCustomValidity("Invalid email address!!!");
            $("#longerrormsg").html("Invalid email address!!!");
        }
        if (reason.valueMissing) {
            evt.target.setCustomValidity("Email must be entered!!!");
            $("#longerrormsg").html("Email must be entered!!!");
        }
    }
    $("#shorterrormsg").show();
});

The invalid event handler grabs the validity object of the email textbox. The validity object gives you more information about what went wrong. If the reason for validation failure is type mismatch (for example, an invalid email address was entered.) the code sets a custom error message using setCustomValidity() method. Similarly, if the value is missing from the email textbox another custom error message is set.

Why do we check that the reason is not customError? That's because we don't want to override the error message from the input event handler. When you set the error message in the input event handler the validity of the email textbox becomes customError. If you don't put this check the error message from the input event handler (if any) will be overwritten by the new value assigned in the invalid event handler.

If you run the application now, you will see the results as shown below:

So far so good. What if you wish to hide the default error callout? In that case you need to modify the invalid event handler like this:

$(document).ready(function () {
    $("#shorterrormsg").hide();

    $("#email").on("input", function (evt) {
       ...
    });

            
    $("#email").on("invalid", function (evt) {
        ...
        $("#shorterrormsg").show();
        evt.preventDefault();
    });
});

Calling preventDefault() at the end of invalid event handler will prevent the display of the default error callout and will display the error messages only in the <span> and <div> elements.

 


Bipin Joshi is a software consultant, an author and a yoga mentor having 22+ years of experience in software development. He also conducts online courses in ASP.NET MVC / Core and Design Patterns. He is a published author and has authored or co-authored books for Apress and Wrox press. Having embraced the Yoga way of life he also teaches Meditation and Mindfulness to interested individuals. To know more about him click here.

Get connected : Twitter  Facebook  Google+  LinkedIn

Posted On : 25 November 2014


Tags : ASP.NET MVC jQuery HTML5