Automatic Validation on the Client

French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

By client-side validation, we refer here to validation that takes place on the user’s browser as it’s processing the form, meaning that the page is not passed to the ColdFusion server to be processed. Instead, the user sees a pop-up JavaScript message that indicates the problem. The user can press the OK button and correct the problem immediately, without needing to back up to correct it. But does this JavaScript pop-up concept scare you? Are you perhaps not familiar with JavaScript? Or worried about cross-browser script-support issues? The great thing about CF’s automatic client-side validation capability is that it creates the JavaScript for you to perform this validation and pop-up such messages. You, the programmer, don’t need to understand or code any JavaScript at all. And the JavaScript that’s created works even in older browser versions. So how do you get the goods? You just need to make a couple minor changes to the form. Indeed, the first thing to do is to change the FORM tag itself to a CFFORM tag (and also change the closing /FORM tag to a closing /CFFORM tag). This tells ColdFusion that you are creating a form that leverages the validation capabilities that we’re discussing here. CFFORM can also be used to introduce some enhanced interface features such as CFGRID, CFTREE, and others. These Java applet-based features are beyond the scope of this article’s discussion about validation and are discussed further. And although we also discuss a CFSELECT tag that does add some validation capabilities, the CFSELECT tag can be used without any validation to easily create drop-down lists (SELECT lists) based on ColdFusion Query results.

The CFFORM tag is an interesting tag, compared to most other tags. It’s clearly intended to be a replacement for the HTML FORM tag, but it adds extra functionality that was not part of the HTML specification. How can this work? How can CF cause a browser to do something that it (theoretically) can’t do? Well, what happens is that the ColdFusion turns the CFFORM tag back into a regular FORM tag, and then it also adds to the page the JavaScript code that’s needed to perform whatever validation you’ve requested. And how do you request validation? You have two kinds of tags for which you can add JavaScript validation, CFINPUT and CFSELECT. As does the CFFORM tag, these correspond directly to their INPUT and SELECT counterparts. So the first step in turning the login form at the beginning of the article into one that uses CF’s built-in JavaScript validation is to simply change the FORM tag pair and INPUT tags into CFFORM tag pairs and CFINPUT tags, as follows:

<cfform action=”login_action.cfm” method=”post”>
   Enter your username and password:<br>
   Username: <cfinput type=”text” name=”username”><br>
 <input type=”hidden” name=”username_required”>
 Password: <cfinput type=”text” name=”password”><br>
 <input type=”hidden” name=”password_required”>
 <input type=”submit” value=”Login”>
 </cfform>

If you look closely, you may notice that we’ve left in the hidden-field validation from the earlier example. Having both client- and server-side validation in a single form is perfectly fine. If for any reason the browser doesn’t support the JavaScript to process the client-side validation that ColdFusion generates, the hidden-field validation can be there to back it up as the form is processed on the server. Although you can keep the hidden fields in place within a CFFORM, you must not change the INPUT tags for those hidden fields to CFINPUT tags. Only INPUT tags that are not type=”hidden” can be used with CFINPUT (including the type values “text”, “checkbox”, “radio”, and “password”.) It really doesn’t appear any differently at all. ColdFusion changes the CFFORM into a FORM tag and the CFINPUT into corresponding INPUT tags and adds some JavaScript code to perform any requested validation. But, of course, if you haven’t yet requested any validation, to using the CFFORM and CFINPUT tags is not logical. As you step toward understanding the feature, however, understanding this characteristic is useful.

Just as with the automatic server-side (hidden-field) validation that we discuss, CFINPUT can be used to indicate either that a field is a required one (meaning that the user must enter a value), and/or it can indicate some particular kind of validation. Indeed, it not only shares most of the same validation types (_date, _time, _integer, _float, and so on), but it also adds additional validations (such as credit card, telephone, and more). We discuss those in a moment. First, take a look at an example of adding required validation by using CFINPUT. It’s different from the hidden-field approach, and yet it’s more straightforward. Instead of adding a new field to the form, you simply add a new attribute-value pair to the tag. Indeed, for required validation, it’s simply a matter of adding required=”yes”, as in the following example:

<cfinput type=”text” name=”username” required=”yes”>

In the example below, we would change both this field and the CFINPUT tag for the password prompt, giving us the following:

<cfform action=”login_action.cfm” method=”post”>
   Enter your username and password:<br>
   Username: <cfinput type=”text” name=”username”
   required=”yes”><br>
 <input type=”hidden” name=”username_required”>
 Password: <cfinput type=”text” name=”password”
 required=”yes”><br>
 <input type=”hidden” name=”password_required”>
 <input type=”submit” value=”Login”>
 </cfform>

Notice that, because the space available [where?], the CFINPUT tags are each split across two lines in the preceding example. The required attribute is specified within the CFINPUT tag. If this form is processed and submitted with no value entered for a username, the result is a JavaScript pop-up message. As a CF developer, you shouldn’t worry about the JavaScript that’s created, but if it interests you, simply use the View➪Source or View➪Page Source command from your browser’s menu bar to display the generated HTML from your page. Whereas CF5 and earlier versions generated perhaps as many as 50 lines of JavaScript code that appeared at the top of the generated HTML, CF MX uses an embedded JavaScript file (using a <script src> tag for those familiar with it), which results in a less verbose script. As is the case with the hidden-field examples, you may also have noticed that the wording of the pop-up error message may not be that helpful. Indeed, it’s an even less friendly Error in username text. That’s perhaps too terse. You can easily improve on it, which is as simple to do as adding the required validation itself (and, again, more straightforward than the hidden-field approach). You can simply add a message attribute with a value that you want shown to the user. You can, for example, change the CFINPUT tag to the following:

<cfinput type=”text” name=”username” required=”yes” message=”Please
   provide your username.”>

Suppose that, in the example, we change this (and the password prompt) to reflect appropriate new wording. Then, if the user submits the form without providing a value in the Username field, the improved message is shown. That’s better. Unlike with hidden-field validation, however, where you see both the username and password validation messages if both are left off, the JavaScript code that ColdFusion creates for CFFORM JavaScript validation (such as in the preceding example, enabled with CFINPUT) shows only one message at a time. Some may find this outcome less desirable, but it’s a limitation that’s not easily avoided. We discuss some possibilities in a moment. For now, just be aware of the behavior. At least one big improvement is that the user remains on the form while addressing these validation issues, as opposed to what happens in server-side validation, where they need to use the Back button to return to the form (and risk losing form data).

You may also recall that the wording of the error message in the value attribute in the hidden- field approach can include HTML tags (such as <b> or <strong>) to help the formatting. Because the wording in the message attribute of CFINPUT is simply passed fore processing as a JavaScript pop-up message, it definitely cannot contain HTML tags. They are not processed. Indeed, the tags themselves would just appear as part of the message. Don’t use HTML in the messages that you indicate for this type of client-side validation. On the other hand, something that you can do to perhaps improve the appearance of these messages is to add JavaScript string-control characters. The \n character, for example, indicates that you want to show a line break or split the message into two lines. The message=” This is line1\nThis is line 2”, for example, displays two lines within the JavaScript pop-up message. This can be handy for improving the formatting.