Home | Audio | DIY | Guitar | iPods | Music | Brain/Problem Solving | Links| Site Map

This work is licensed under a Creative Commons License.

Performing Full-Featured Form Validations

Joseph Lowery
idest.com

Forms appear all over the web. However, they often lack one essential element: validation. Form validation is quite important for both web users and developers. Users are guided by receiving clearly stated responses to errors, while developers will find that validation keeps bad data out of the data source.

There are several different kinds of form validation. Perhaps the most frequently applied type of validation is one that ensures that users fill out required fields correctly. Other validations specify which characters users can or cannot use in an entry, or ensure that users only enter a certain format (such as for a date).

Macromedia Dreamweaver has included a Validate Form client-side behavior since its very first release. Although this degree of form validation is conveniently built-in, the behavior itself is limited in its functionality. For example, you cannot ensure that users make a choice from a pop-up menu. Moreover, you can only check for the presence of text, number, or number range in any given field; you cannot validate an entered phone number, credit card number, or social security number.

Built by WebAssist, the WA Validation Toolkit offers both client-side and server-side validation methods. It supports the ASP-VBScript, ASP-JavaScript, ColdFusion, and PHP server models, and ships with 15 validation behaviors, including the ability to create custom validations with regular expressions. All behaviors work in conjunction with five different response behaviors to alert users when they have entered invalid content into a form, or perform other actions such as enabling or disabling another form element. If you have DRK Volume 9, it contains the WA Validation Toolkit Recipes, which are a series of step-by-step instructions that show you how to get the most out of the WA Validation Toolkit.

For ease of use, the WA Client Validations Wizard portion of the toolkit can't be beat. In three steps, it configures and applies selected validation behaviors along with the Show Validation Errors behavior to a specified form on your page. Additionally, existing WA form validation behaviors on the page that are applied to the onSubmit event of a selected form—either separately or through the wizard—are inspected and can be edited using the wizard. The WA Client Validations Wizard provides a clear and simple path to straightforward client-side validation.

This article explores the WA Validation Toolkit and shows you how to combine both server-side and client-side form validations for a better user experience that can eliminate browser errors for your users and prevent bad data for you.

Combining Server-Side and Client-Side Validations

When combining server-side and client-side validations, focus on the strengths of each and avoid duplication of effort. For example, it's best to apply the WA Server Validations server behavior—which is triggered when a user submits a form—and not use the Client Validations Wizard, which also applies submit-triggered behaviors. Client-side validation is applied to individual form fields and triggered by the user moving through the form; server-side validation takes place all at once and is independent of the user's JavaScript setting. You can find a complete comparison chart of client-side and server-side supported validation properties in the WA Validation Toolkit Recipes documentation, available for free from WebAssist.

The form I validate in this article is a relatively simple one that includes four text fields: First Name, Last Name, E-mail, and Confirm E-mail (see Figure 1).

Figure 1. Sample form to validate

The validation process consists of three primary steps:

1. Apply basic server-side validations to check for required fields when a user submits the form.
2. Add client-side validations to check—on the fly—the e-mail fields for correct format and to verify that the second e-mail field matches the first.
3. Insert server-side error messages that appear conditionally.

The order that I use to describe these steps is just one scenario. I prefer to handle most server-side validation first, followed by client-side validation, because it makes me feel as though I'm getting the bulk of the work out of the way right up front. The separate validation tasks do not conflict with each other in any way.

Forms are often a two-column affair, with one column for labels and a second for form elements. From a design perspective, however, it's important to keep in mind that the completed form will include embedded error messages. Therefore, I've found that adding a third column allows individual error messages to appear that are both user- and designer-friendly.

Applying Server-Side Validations

First, you apply server-side validations to supply the basic level of validation. In all, five validations are coded for the four different form elements through the WA Server Validations server behavior. Even though you will add client-side validations to the e-mail fields later (to check whether they have been filled out properly with matching values), those validations are triggered by the onBlur event. By including a validation at the server-side level, you ensure that users are notified of a problem before they fill out all the fields.

Here are the steps to apply a server-side validation:

1. From the Server Behaviors panel, select Add (+) and select WebAssist Validation Toolkit > Server Validations to display the WA Server Validations dialog box (see Figure 2).

   

   Figure 2. WA Server Validations dialog box

2. Choose the action to trigger the validations by selecting Current Page Submit from the Validation Trigger list.

In the WA Validation Toolkit, you can trigger form validation in any number of ways: when any form on the page is submitted, when a form from another page is posted to the current page, before the page loads, or when specific submit buttons are clicked.

Now it's time to set the specific validations for each form element. The general workflow is to select the type of validation desired, choose the form element you want to validate from the dynamic listing, click Add (+) to open the chosen validation's dialog box, and select any parameters for the validation.

Let's start with the First Name field:

1. Apply the Alphanumeric validation to the First Name field:
   1. Select Alphanumeric from the Form validation list.
   2. Click the lightning bolt and select First Name from the theForm node.
   3. Click Add (+).
   4. Set the parameters to allow both uppercase and lowercase letters as well as spaces, but not numbers. In the Allow Other field, enter a period because this field could potentially hold middle initials. Make sure to deselect the Allow Blank Entry option (see Figure 3).

   

   Figure 3. Setting parameters for Alphanumeric validation

2. Repeat Step 1 for the Last Name field. Make sure you allow numbers for this field because last names may include Roman numerals (for example, Jameson III).
3. Apply e-mail validation to the Email field; no additional parameters are necessary for this field.
4. Repeat Step 3 for the Email2 field.
5. Apply Like Entry validation to the Email2 field. In the Like Entry dialog box, set the Same As field to Email. This validation compares the two fields.
6. Click OK to close the WA Server Validations dialog box.

Like any other server behavior, when you apply a server behavior from the WA Server Validation toolkit, you can reopen and change it at any time.

Setting Client-Side Validations

To tell you the truth, you could easily skip this step and still be assured that users entered their data in the required format—the server-side validations take care of that. However, relying on server-side validations only does not lead to great user experiences. When filling out a form, users tend to find it difficult to locate errors on a page when the browser reports the errors only after the user has clicked the Submit button. The presence of numerous errors can be disconcerting as well. Client-side validations check the form as users fill it out; if a user makes a mistake, an alert instantly appears, leaving no question as to the location of the problem.

The following steps apply to client-side behaviors that check the validations of the two e-mail fields and also adds behaviors to show an error message, if necessary:

1. Select the first field to validate, namely Email.
2. From the Behaviors panel, click Add (+) and choose WA Validation Toolkit > Apply Client Validations > Email Address.
3. Set the parameters by deselecting the Allow Spaces Without Characters option and changing the error message to this (including the hyphen): – Invalid Email Address.
4. Set the If Error Occurs option to Stop Validation (see Figure 4).

   

   Figure 4. E-mail Address validation prevents users from submitting improperly formatted e-mail addresses

   When the Show Validation Errors behavior fires, it displays a general error message and each of the pertinent specific messages that are active at the time. The leading hyphen indents the specific message about the e-mail validation under the general message.

5. Click OK. You may need to adjust the event so that it triggers when the user tabs out of the field.
6. If the event for the just inserted behavior is not onBlur, select the current event and choose onBlur from the list.

Adding the error message behavior is just as easy:

1. Make sure that you have selected the Email form element.
2. From the Behaviors panel, click Add (+) and choose WA Validation Toolkit > Show Validation Errors.
3. Set the parameters by changing the Error Header to The following error was found and change the Error Footer to Correct the invalid entry to continue.
4. Leave the other options as they are and click OK to close the dialog box.
5. If necessary, change the event to onBlur.

Test the form at this point if you like. When you preview the form in a browser, try tabbing through the fields from the beginning; the form will stop you immediately after leaving the initial e-mail field.

To complete the page, add the Like Entry and Show Validation Errors behaviors to the second e-mail field; the process is identical.

Inserting Server-Side Error Messages

The final step in implementing form validation is to add validation error messages. Here, you will take advantage of server behaviors in the WA Validation Toolkit to show any region if validation fails. I like to use two different types of messages: a general message that informs users that there is a problem and guides them through the overall process, and specific text that appears next to the invalid field and tells them exactly what the problem is.

Here are the steps to insert a server-side error message:

1. In the top row of the table, insert a general error message, like the following message:

   * Please correct the indicated errors and re-submit.

   Style error-message text so that a user can immediately notice it; a bright red font is an obvious, but appropriate choice.

2. Highlight the text you just added and, from the Server Behaviors panel, select Add (+) and WA Validation Toolkit > Validation Show If.
3. In the Validation Show If dialog box, set the parameters by making sure the Validation Page field is set to the current page, setting the Validations Fail field to Any, and clicking Add (+) to confirm the validation (see Figure 5).
4. Click OK to insert the code and close the dialog box.

   

   Figure 5. Setting parameters in the Validation Show If dialog box

A similar series of steps is required for adding the specific error messages:

1. In the column next to the Email field, enter text, as follows:

   * Enter valid e-mail address

2. Highlight the text you just added and, from the Server Behaviors panel, select Add (+) and WA Validation Toolkit > Validation Show If.
3. Set the parameters by making sure the Validation Page field is set to the current page, setting the Validations Fail field to Email, and clicking Add (+) to confirm the validation.
4. Click OK to insert the code and close the dialog box.

Add one more error message for the second e-mail field and behavior combination to complete the page.

Whenever you test your pages, it's always best to try every combination of data entry you can think of. If possible, set a web novice loose on your form. You'll quickly see how necessary form validations are—and how a full-featured approach to form validation is perfectly...valid.

About the author

Home | Audio | DIY | Guitar | iPods | Music | Links | Site Map | Contact

Top