At this point, the cfform tags looked pretty good: They were a lot faster and worked a lot smoother, but something else was missing. For years, users had requested new validation types, such as e-mail and URL. There had also been many complaints about having only JavaScript validation for the client side (what if the client has JavaScript disabled?). Other complaints were about the server-side validation we supported (it required developers to use HTML hidden fields). In addition, when you used server-side validation, you couldn't validate all of the same types of data as you could with client-side JavaScript validation, which caused a frustrating discrepancy between different validations techniques.
To fix these issues, we synchronized all of the validation routines from the client-side JavaScript with the validation libraries on the server. There were a few differences we couldn't change for backwards compatibility. For instance, server-side date parsing validation allows more date formats than the client-side JavaScript validation; however, if you call e-mail validation on the client or on the server now, ColdFusion runs the same regular expression to validate it. Of course, calling these validation routines was still annoying because you still had to code an HTML hidden field to trigger each field. Although using hidden fields is still a useful way to validate data on intranets or other applications where you control who uses your application, there is a problem using hidden fields to validate data on a public site: Someone could hack your site and remove the hidden fields, bypassing any validation you thought was in place. We did a few things to resolve this problem.
If you use the hidden fields, ColdFusion MX 7 automates their creation. As you may know, previously you had to code an input field and a hidden filed for server-side validation. Now you don't need to remember the cryptic syntax to trigger the validation in ColdFusion.
Before:
<cfinput type="text" name="fname" required="true"> <input type="hidden" name="fname_required" value="Fname is required">
After (in ColdFusion MX 7):
<cfinput type="text" name="fname" required="true" validateat=" onServer">
You use the new validateAt="" attribute to define three different location values to validate: onSubmit (this is the default option), onBlur (a new validation location type), and onServer. You can mix and match these values or specify the validation locations you would like to use as a comma-separated list:
validateAt="onBlur,onServer"
On a ColdFusion page—especially a form action page—it is a common and best practice to validate all variables passed into the page. To make this easier for you, we added access to all server-side validation routines in the cfparam tag through the type attribute. Thus, you can verify whether the variable exists and, at the same time, validate the value as a specific data type, all in one tag (this even includes the powerful "RegEx" validation type).
Example:
<cfif isDefined("form.submit")>
<cfparam name="form.email" type="email">
<cfparam name="form.password" type="regex" pattern="[a-z]{1,3}[0-9]{6,10}">
<!---
Your custom form submission logic goes here
--->
</cfif>
Because this may not work for all solutions, we didn't stop with the cfparam tag but, rather, added a new ColdFusion function, the IsValid() function as well. Use this function to call validation routines against any variable (for instance, you might want to validate against a value you query from a database).
Example:
<cfif isValid("email", myQuery.usersEmail)>
<cfmail from="webmaster@mysite.com"
To="#myQuery.usersEmail#"
Subject="System Update">
This is to inform you that at 2pm today ...
</cfmail>
</cfif>
Again, we could have stopped here, because the cfform tags were now a solid tag set with plenty of new functionality. Instead, we knew that this new foundation gave us stability and an opportunity to have some fun, reinventing the way you build forms in web applications.