Using Dojo for Client-Side Validation / Page 2

Using Dojo for Client-Side Validation [con't]

2.2.2 Validating the Last Name Field

The last name field has the same validations as the first name field does. There is nothing extra to do for this field and nothing new to learn. Just replace the <input> tag for Last Name with the following code.

2.2.3 Validating the User Name Field

We are going to allow the user to manage his or her own account information in our application. To provide some security we need the user to make up a user name that he or she can use later to sign on to the system. This field will be required,and we'd like it to always be entered in lowercase. To validate this field,we'll use the same Dojo widget that we've already used, dijit.form.ValidationTextBox, but we'll use a new attribute called lowercase to force the transformation of the entered data into all lowercase letters.

There are some additional validations we'd like to do on this field. For instance, is this user name already assigned to someone else? We could check the server for existing values. However, because this validation requires interaction with the server, we'll save it for step 3 of the tutorial and focus on only the client-side validation right now.

The following HTML markup is needed to enable validation for this field.

2.2.4 Validating the Email Address Field

We need to communicate with our customers so we'll get their email addresses. This will be a required field.We'll also make it all lowercase for consistency. In addition, we'd like to make sure that the value entered in this field is also in the correct format for an email address. There is no way to know if it is a working email until we actually try to send something to it, but at least we can make sure that it contains a "@" character and appears to reference a valid domain.

How can we specify the desired format? By using a specialized pattern matching language known as regular expressions, we can specify a pattern of characters to check the value against. We need to build a regular expression to validate for email addresses. At this point in our discussions, let's not go on a long detour to discuss the building of these expressions.

NOTE: Some great information on building regular expressions can be found at the Mozilla Developer Center.

The following is regular expression that can be used to validate most formats of email addresses—most because it is surprisingly difficult to validate for all possible email addresses. This is because of some of the unusual variations such as domains longer than four characters such as ".museum" or addresses consisting of a sub-domain. But the following regular expression will work for most.

NOTE: For more information on validating email addresses, read this Dojo Forum article describing a regular expression for email.

The ValidationTextBox contains a special property for validating against regular expressions. The attribute to use is regExp—just specify the regular expression as its value. Replace the <input> tag for email with the following code in "form.html" to specify validation for the email address field.

Validating email addresses is a really interesting subject. There are quite a few variants to the simple [email protected] format that we often see. For a really thorough discussion of email,you should review the RFC rules. This Wikipedia page describes email, from which you can link to the official RFC documents.

2.2.5 Validating the Address Field

The address field will contain the first line of the user's mailing address. We'll make it required. We will use the ValidationTextBox, and we have seen all of the attributes already. Replace the <input> tag for address with the following code.

There are many additional validations that can be performed on address data, the most important being to ensure that the address is an actual address. Standard abbreviations such as "St"for "Street"could also be allowed. These additional validations could be done by a number of web services available from the U.S. Postal Service, but that is really outside the scope of this tutorial.

2.2.6 Validating the City Field

The city field will contain the value for the city in the user's mailing address. We'll make it required.We will use the ValidationTextBox. Replace the <input> tag for address with the following code.

2.2.7 Validating the Zip Code Field

The zip code field is part of the mailing address and is required. There are some additional validations we can apply. Our hypothetical company is a U.S. corporation and only provides service to U.S. customers, so we'll limit our address to valid U.S. addresses, which means that the zip code must be in one of two forms. Either it is a 5-digit number, or it is a 5-digit number followed by a dash and then followed by a 4-digit number. If we can come up with a regular expression to test for either format, then we're golden!

Replace the <input> tag for zip code with the following to enable Dojo validation for this field.

An interesting feature of the preceding code is that we've got two overlapping validations. The maxlength attribute prevents the value from being over 10 digits, but so does that regular expression. What are the implications of this? One could argue that it is inefficient because both validations will be executed. But they each operate differently on the page, which might justify using both. If the user tries to enter a zip code that is 12 digits long, he will be notified as he tries to type the eleventh digit, rather than after typing all 12 digits and pressing tab to leave the field. By using both techniques, the error is detected sooner.

NOTE: This chapter has stopped short of describing validations for the "Start Service" and "Comments" fields. This is because we will use more advanced Dojo widgets to validate these fields, which are described in Chapter 4, "Using Dojo Widgets."

Summary

The Dojo widget dijit.form.ValidationTextBox provides many common client-side validations. Include the ValidationTextBox by referencing it in the <input> tag for the field that needs the validation.

Remember to tell the page that it needs the JavaScript code for the widget by coding a call to the require method somewhere after the call to the Dojo parser.

Additional attributes in the <input> tag specify behavior for the ValidationTextBox. A few are listed here:

require="true" makes the field required.
trim="true" removes leading blanks.
lowercase="true" converts field to all lower case letters.

We've now completed step 2 of the tutorial. The changes we've implemented have added client-side validation to our form. We were able to add validation almost exclusively through modifying the HTML—only a small amount of JavaScript was necessary to include the Dojo validation code. Client-side validation is an extremely powerful capability and makes our page much more usable. Yet by using Dojo, we obtain this power without the corresponding cost of writing a lot of JavaScript.

In this chapter we've focused on functionality that doesn't require a call to the server. In the next chapter the server will play a role. We'll make calls to the server using the XMLHttpRequest to get data and perform validations. Now that's Ajax!

This chapter is an excerpt from the book, Dojo: Using the Dojo JavaScript Library to Build Ajax Applications by James E. Harmon, published by Addison-Wesley Professional, December 2008, ISBN 0132358042, Copyright 2008, Addison-Wesley Professional, Inc. All rights reserved.

Original: January 30, 2009

[prev]