For Web developers, form validation is a basic task, and yet one that presents some interesting challenges. Even discounting security issues such as SQL injection attacks and cross-site scripting (XSS), form validation is a critical step in your error handling strategy.

The two criteria I use to plan a form validation approach are extensibility and simplicity. Forms will change over time. It's like death and taxes, and much like those two events it's a lot better to plan for them before the fact, rather than after. When your form changes, how easy will it be to change your validation? When your business rules change, as they often do, how easy will it be to update your validation? How easy will it be for someone else to update your validation code if they were not a part of the original development effort? Fortunately, an object-oriented approach handles all of these questions.

Data validation is really two different activities. First, you need to validate the data. Is a date of birth really a date? Does that credit card number follow the Mod10 algorithm? Second, you need to determine how the data fits into your business rules. Suppose a date of birth of 03/06/1902 was passed in. It's certainly a valid date, but if the point of your application is to sell life insurance policies, then that date will likely not pass your business rules.

Basic data validation and validation of business rules are two different activities, and yet they are so often handled as one. For example, how often have you seen something like this:

<cfif not Isdate(form.dob)>
    <cfset errormsg = "Please enter a valid date of birth">
<cfelse>
    <cfif Year(form.date) GT 1950>
       <cfset errormsg = "Applicant is not eligible for this insurance policy">
    </cfif>
</cfif>

Except for the gross oversimplification of age checking, done for example purposes, this approach is workable, but can be bulky when applied to a large form. Worse, as the business logic is embedded in the datatype validation, the code for the business rule validation must be re-written in order to be used elsewhere.

Thankfully, there's a better way to handle this. To examine a more flexible, reusable approach, let's consider a very simple form. We're going to collect first and last name, date of birth, and country of citizenship, and then we'll validate the input both for correct datatype and business rules.

Validation Bean
Before we start checking for errors, we need some method of collecting errors and error messages. It is so annoying when a Web application tells you that your input was incorrect in some way, but will not tell you what exactly was incorrect or why. Finding errors is only half of the solution; reporting them to the user is the other half. To that end, I use a ValidationBean object (see Listing 1). Using an object to hold validation information creates a standard interface for validation tasks.

The ValidationBean has two properties: Result and Message. Result is a simple Boolean, indicating whether or not the form data passed validation. The Message property is an array of error messages. Along with the necessary getters and setters for these properties, the ValidationBean also has an appendMessage() method, which adds another error message to the Message array, and a Reset() method, which simply clears the error messages and sets the Result to True. I use this method during validation to clear out any results from previous form submissions.

Datatype Validation
The ValidationBean is extremely generic, so at this point you're probably wondering where and how the datatype validation takes place. I put datatype validation within the bean(s) that hold form data. The idea behind this is that the bean should be somewhat self-aware. A bean doesn't need to know how its data is going to be used, but it should have some idea of what its data is and the format for that data.

As you look at the code for formBean.cfc (see Listing 2), a couple of things may stick out. First of all, the setters have an argument with a type of "any" and the getters have a returntype of "any".

Second, all arguments are optional and have a default value, which means that all variables-scoped variables are assured to be assigned a value. This may require some additional explanation, because it may seem better to set the argument types and the returntypes to the datatype that is expected. I find this approach limiting, however. The form bean is a representation of the form data as it was entered. If an incorrect type of data is entered, or if a form control is left blank, I don't want the bean throwing an error. I prefer to find and deal with the problem programmatically.

To handle validation, I include a Validate() method. I pass in a Validation Bean as an argument, and since ColdFusion passes CFCs by reference, it is not necessary for me to return anything from this method. The method can inspect each attribute in the bean and return an error message customized to the form control in question.

At this point what we have is an object that holds the data passed in through a form. This object has an interface for returning data, and the ability to inspect the data it holds to make sure that it is of the expected type. However, it doesn't know how this data is to be used. This is useful if you want to use this form data in several different applications. Consider the example above. Name, address, date of birth and the like are common pieces of information to pass through a form. Using a form bean to hold and validate data commonly passed in through a form, you don't have to duplicate work on other applications that use this same data. Validation rules are consistent from application to application, and you have the advantage of using an object whose behavior is well tested and well known.