Testing the length of a TextArea field

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

Although the automatic client-side validation provided by ColdFusion is very simple to use, we’ve identified a few limitations. Still other forms of validation are available that you may want to perform that are not supported either by HTML forms or by CFFORM. In such cases, you must hand-code that validation. You can do the validation either on the client (in JavaScript) or on the server (in CFML). Admittedly, coding JavaScript isn’t a trivial matter, and understanding it fully is beyond the scope of this article. To learn more about JavaScript, you can check out a couple excellent resources. One is The JavaScript Bible by Danny Goodman, from Wiley. Another is JavaScript: The Definitive Guide, by David Flanagan, from O’Reilly. For a simpler introduction to incorporating JavaScript into your ColdFusion pages, see the June 2000 CFDJ article, “Getting Focus(ed)—And a Quick JavaScript Overview,” by Charlie Arehart. Although we have no room to explain JavaScript coding in depth, at least a few ideas are worth considering here. The first is also very easy to add without much JavaScript knowledge. Have you ever wanted to limit the length of data that someone can enter in a field created by the HTML TEXTAREA tag? As opposed to the INPUT tag, which permits only a single line of data to be entered, the TEXTAREA tag enables users to input long, multi-paragraph text.

But what if the input of that TEXTAREA is passed (in the action page) to a SQL INSERT or UPDATE statement that places that data into a database with column definitions of a limited length? If you don’t test to ensure that the user’s data fits in that specified size, the INSERT or UPDATE fails. Unfortunately, whereas the INPUT tag has a maxlength attribute, in HTML, you have no way to limit the length of a TEXTAREA field. This is a surprisingly easy test to add, however, if you know the appropriate JavaScript. Again, we have no space to explain this procedure in detail, but assume that you have a TEXTAREA field such as the following:

<textarea name=”description” rows=”10” cols=”50”
   wrap=”virtual”>
 </textarea>

To add a test for length, you have a couple of choices, but perhaps the simplest to explain is to leverage the available onchange attribute. This attribute can be used to specify some JavaScript (right inside the value of the attribute) that is executed whenever the user changes the value of the TEXTAREA field. This is an appropriate solution to our problem. To add the test for length, you simply need to know the JavaScript code for referring to the value of the field and for testing its length against some maximum number. Even without knowing JavaScript, you can easily use this as a model. To add a test to the preceding example, change the example as follows:

<textarea name=”description” rows=”10” cols=”50”
   wrap=”virtual”
   ONCHANGE=”if (this.value.length > 2000) {
   alert(‘Description must be limited to 2000 chars.’)};”>
 </textarea>

This code will display a JavaScript alert box when the user types over 2,000 characters. You can easily add this code to your own examples. Just copy the entire onchange attribute and its value, changing the length value (2000 in the preceding example) to whatever maximum that you want. Of course, the message should be changed as well to reflect whatever on-screen prompt the field has for the user. You’d change the string inside the quotes after alert. (Just be careful not to split the string over multiple lines. JavaScript does not permit strings to be split that way. Some other validations where you may consider using this approach are also possible. Some of them may take more effort to understand the JavaScript to make them happen.

Whether, in a SELECT control, a choice was made other than a Select One option that may have been placed at the top of the list to guide the user. (Something that could prevent submission or force assignment of some default value.)

Whether a date entered is in the past or future, as you want it.

Consider carefully other possibilities that may exist in your application to test for. The possibilities expand if you also consider that, with ColdFusion generating the HTML (and JavaScript) that’s sent to the browser, you can also create validations on the client that are based on comparisons with data that’s sent from the server. This is an interesting, but clearly intermediate, challenge. Of course, many of these examples of testing can be performed on the server side as well. But performing validation on the client can be so much more effective in providing a good experience for a user.

Before we conclude this article with a part on server-side validation in CFML, however, you need to know about one other form of client-side validation. It’s not a built-in feature of ColdFusion, but it is something written by a member of the ColdFusion community, Dan Switzer of PengoWorks. Best of all, it’s free (and open source). The very simple installation process not only provides the tool, but also excellent examples and documentation. Just run through the examples to see the sort of things that are possible. We have no room to explain the use of qForms in detail, but know that it can perform many useful tasks in processing forms, including more effective error messaging. Just by adding a few lines of simple JavaScript and pointing to a provided Cascading Stylesheet file, qForms can perform many of the same validations (indeed, more) but adds more power and finesse to the process. In addition to providing a JavaScript pop-up such as the one that CF MX offers, for example, qForms can also provide color-coded indications of the specific fields on the page that are in error. The included examples easily demonstrate this. Other features include the option to perform validations on leaving each field (rather than on submitting the form). qForms can also permit different parts of the form to be validated based on other data entered on the form, can enable you to change SELECT values based on choices made in another SELECT control, and lots more—again, all for free! The final form of validation that we cover in this article is hand-coded validation that takes place on the server—in other words, coding CFML to perform validation, such as on a form’s action page. This type of validation is an important alternative for several reasons, including the following:

It enables you to perform additional validations (which are not available otherwise).

It enables you to performing data processing/integrity checks.

It enables you to back up client-side validation.

Occasionally, the built-in automatic validations (client- and server-side) of ColdFusion may fail to meet some need that you have. In that case, if you must code a manual solution, you are probably more comfortable coding in CFML than in JavaScript. If you following the explanations elsewhere in this article about how to perform conditional tests, how to process form fields, and how to use certain important functions, this type of validation is pretty straightforward. Indeed the article shows the basics of validating form input to perform SQL processing. Just be aware that having the user perform validation on the client clearly has value (and, indeed, value in terms of reduced processing resources on your server). You may perform still other forms of validation in your form action page by using CFML. Again, some of these are covered in other articles and may not be thought of strictly as validation, although to a degree they really are. These include such procedures as the following:

Checking a username/password combination on logging in.

Validating that the quantity on hand for an order is still available (before processing an order from a form submission).

Ensuring that expected URL, Session, or other variables exist on the page before proceeding.

Checking any URL or FORM variable values used as input to SQL clauses to ensure that no strings other than those expected are processed. Some other validations of form entries may relate more to the relationship between one entry on the form and another. You may, for example, want to validate that the following situations are true:

If one check box is selected, another other can’t be selected.

If one SELECT option is chosen, some other field can’t be (or must be) chosen. Eearlier in this article, we showed that it has features to perform that sort of validation on the client, but you may want to back that processing up on the server in case the browser doesn’t support JavaScript. Indeed, this leads to the last reason to consider some sort of hand-coded server-side validation. For all the power and effectiveness of client-side validation, it can possibly be bypassed. The browser may not support JavaScript, for example, or it may not support the particular JavaScript that you (or ColdFusion) provides. Maybe you don’t think that you need to worry about old browsers such as that. Something that may surprise many, however, is that some organizations (and individuals) choose to disable JavaScript support in their browsers because of security concerns. If they disable it, whatever nifty validation you’ve got on the client (whether hand-coded or automatic) doesn’t matter. The validation can’t take place. In such a case, the capability to perform server-side validation becomes especially important. Indeed, this suggests very strongly that performing hand-coded server-side validation to back up whatever client-side validation you may be performing is in your interest. Of course, one may argue that the automatic server-side validation that we discuss at the beginning of the article, should serve as an adequate backup for that sort of situation. But can you think of why that may still not be enough? When may your form’s action page be executed without the form being processed at all? What if the user bookmarks the action page (or types in its URL) to visit it directly? Or what if he uses something such as CFHTTP, which we discuss later and is available on other application servers with similar capabilities? Such a user could intentionally try to process your form’s action page by sending a real form posting but not really executing your form. In that case, the user could also remove any client-side validation or hidden-field validation that you placed there. In these days of security concerns and hacking, you need to take such issues into consideration. Even if such an effort isn’t with the intent to do harm, if the client-side validations that you have in place are intended to prevent database errors because of invalid input. Recall the TEXTAREA maxlength test from earlier in this article: If validation wasn’t performed on the client (and backed up on the server), the user may experience unexpected database errors.

In this article, we describe two major forms of validation—those that take place on the client (in JavaScript) and those that take place on the server (in CFML). We also show you that ColdFusion MX includes mechanisms to automatically handle both forms of validation. The hidden-field capability offers automatic server-side validation (although, of course, the specification is sent to the client but is processed on the server). It enables you to test for certain expected data types and string formats, but the appearance of the error message and the need for the user to press the Back button to correct mistakes (and possibly lose data because of browser caching features) make this type of validation less desirable for all but the simplest forms. Client-side validation, by using JavaScript, offers several advantages. The nice thing about CFFORM and its associated CFINPUT and CFSELECT tags is that they cause CF MX to auto- matically build JavaScript for you. They also add validations for things such as credit cards, telephone numbers, and zip codes. These last two follow only U.S. formats, however, and have some other limitations, so we explain how the new CF 5 feature of supporting regularexpression patterns in CFINPUT gives you much more freedom and capability (at the cost of learning how to write regular expressions). Creating such validations on your own leads naturally to a discussion of performing your own hand-coded client- and server-side validation. In each case, the cost is simply the effort of creating the language constructs and algorithms (in JavaScript or CFML, respectively) to perform the needed validation. Finally, you learn that you may want to back up the client-side validation by using server-side validation, even though such a course may seem redundant, to support those situations in which the client-side validation is bypassed either because of lack of JavaScript support in the browser or by intentional (or unintentional) bypassing of the form.