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.
Business Rule Validation
Validating input against business rules is generally more in depth than validating data types. It helps to think of this as giving context to your data. A name, address, and date of birth are nothing more than a set of unrelated data. Once you have applied business rules, however, you have a customer. If business rules give your data meaning, business rule validation ensures that your data is given the correct meaning.
Datatype validation objects are much easier to share than business rule validation objects. This sort of validation is very specific to a given task or application. However, since we are breaking validation into two parts, we can rewrite our business rule validation objects as necessary and reuse our datatype validation objects. Object-oriented applications are really nothing more than a group of objects that are communicating with each other. You, the developer, are free to determine which objects will be a part of a given application. Since our validation objects are loosely coupled, meaning one object doesn't rely on another, we can change out objects as we see fit.
As an example, let's assume that in this particular application our customers need to be between the ages of 13 and 18, and they also need to be citizens of the United States. I would create a Validate() method, perhaps in a customer.cfc object, to check to make sure that the birthdate and citizenship fit the specified parameters. Although this has some similarities to our Validate() method above, the differences are worth pointing out. When validating datatypes, the formBean has no idea how the data will be used. It just knows which form the data is to take. A Customer object, however, is not so much concerned with the representation of the data, but whether or not the data presented can be used to create a valid customer for this application.
Putting It All Together
How you put this all together is really up to you and how you construct your applications. Are you a procedural developer who includes a validation template on a form page once a form submission has been detected? No problem. Your validation template might look something like this:
<cfset datatype = CreateObject("component","myApp.formBean").init(argumentcollection=form)>
<cfset customer = CreateObject("component","myApp.customer").init()>
<cfset validationBean = CreateObject("component","myApp.validationBean").init()>
<cfset datatype.Validate(validationBean)>
<cfset customer.Validate(validationBean)>
<cfif ArrayLen(validationBean.getMessages())>
<!--- Do something to display the error messages --->
<cfelse>
<!--- No errors. Continue the application --->
</cfif>
Since I use Mach-II for most of my development needs, I would have an event-bean declared in the mach-ii.xml configuration file for this event, and I would use that bean's Validate() method in an event filter, which is where I would also create my validationBean and, if necessary, any object needed for business rule validation.
Conclusion
Form validation isn't one of those tasks that I look forward to in the morning. Not that I particularly dislike it, but it's just one of those chores of Web development. The object then (no pun intended!) is to make form validation as easy, flexible, and reusable as possible without sacrificing accuracy or functionality.
This is one of the strengths of object-oriented programming. Rather than building one monolithic, interdependent application, it's more like building a house with Legos. This allows you to spend less time on development chores, like form validation, and more time deciding how the Legos should fit together for your application.