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.
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.
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
firstname.lastname@example.org 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!
<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."
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.
require method somewhere after the call to the Dojo parser.
Additional attributes in the
<input> tag specify behavior for the
few are listed here:
require="true"makes the field required.
trim="true"removes leading blanks.
lowercase="true"converts field to all lower case letters.
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!
Original: January 30, 2009