Understanding Form Validation - macromedia COLDFUSION MX 7 Web Application Construction Kit [Electronic resources] نسخه متنی

Understanding Form Validation

<271 forms are used to collect data from users by using several field types. Forms are used for data entry, as front-end search engines, for filling out orders, for signing guest books, providing user names and passwords to secure applications, and much more. Although forms have become one of the most important features i269, these forms provide almost no data validation tools.

This becomes a real problem when developing Web-based applications. As a developer, you need to be able to control what data users can enter into what fields. Without that, your programs will constantly be breaking due to mismatched or unanticipated data. And thus far, you have used forms only as search front endswhen forms are used to insert or update database tables (as you'll see in Chapter 14, "Using Forms to Add or Change Data"), this becomes even more critical.

Thankfully, ColdFusion provides a complete and robust set of tools with which to implement form data validation, both client-side and server-side.

Since its inception, HTML has always provided Web page developers with a variety of ways to format and display data. With each revision to th260 specification, additional data display mechanisms have been made available. As a result, HTML is a powerful data-publishing tool.

Although its data presentation options continue to improve, HTML's data collection capabilities leave much to be desired. In fact, they have barely changed at all since the language's very early days.

<271 data collection is performed using forms. HTML forms support the following field types:

• Free-form text fields

• Select box (or drop-down list boxes)

• Radio buttons

• Check boxes

• Multi-line text boxes

• Password (hidden input) boxes

Chapter 12, "ColdFusion Forms," for more information abou275 forms and using them with ColdFusion.

So what's wrong with this list? Actually, nothing. These field types are all the standard fields you would expect to be available to you in any development language. What is wrong, however, is that these fields have extremely limited capabilities. There are two primary limitations:

• Inability to mark fields as required

• Inability to define data types or filters, for example, to only accepting digits, a ZIP code, an e-mail address, or a phone number

What this means is that there is no simple way to tel267 to disallow form submission if certain fields are left empty. Similarly, HTML can't be instructed to accept only certain values or types of data in specific fields.

<271 itself has exactly one validation option, the maxlength attribute, which can be used to specify the maximum number of characters that can be entered in a text field. That's itno other validation options are available.

To work around these limitations, HTML developers have typically adopted two forms of validation options:

• Server-side validation

• Client-side validation

Comparing Server-Side and Client-Side Validation

Server-side validation involves checking for required fields or invalid values after a form has been submitted. The script on the server first validates the form and then continues processing only if all validation requirements are met. Typically, an error message is sent back to the user's browser if validation fails; the user then goes back to the page, makes the corrections, and resubmits the form. Of course, the form submission must be validated again upon resubmission, and the process must be repeated if the validation fails again.

Client-side scripting lets the developer embed instructions to the browser within th260 code. Becaus260 itself provides no mechanism for doing this, developers have resorted to using scripting languages, such as JavaScript, which is supported by just about every browser. These interpreted languages support basic data manipulation and user feedback and are thus well suited for form validation. To validate a form, the page author would create a function to be executed as soon as a Submit button is clicked. This function would perform any necessary validation right inside of the browser, and only allow the submission to proceed only if the validation check was successful. The advantage of this approach is that the user doesn't have to submit a form to find out an error occurred in it. Notification of any errors occurs prior to form submission.

Pros and Cons of Each Option

Neither of these options is perfect, and they are thus often used together, complementing each other. Table 13.1 lists the pros and cons of each option.

From a user's perspective, client-side validation is preferable. Obviously, users want to know what's wrong with the data they entered before they submit the form for processing. From a developer's perspective, however, server-side validation is simpler to code, guaranteed to always work regardless of the browser used, and less likely to fall victim to browser incompatibilities.

TIP

Form field validation should never be considered optional, and you should get in the habit of always using some type of validation in each and every form you create. Failure to do so will inevitably cause errors and broken applications later.