Validating Input with Regular Expressions @ JDJ

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

<script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

  Have you ever wished CFInput provided a way to

  validate an e-mail address? Or were you frustrated that its telephone validation didn't allow parentheses around an area code among other such limitations?

  Well, your wish has been granted in a new, little-known feature of CF5.

  While many will know of the top 10 or so new features in CF5, few will know about the dozens (yes, dozens) of less-promoted enhancements. One of these is the ability to validate user Input by way of Regular expressions. (If you're new to Regular expressions, we'll show you some examples and point you to the CF docs where you can learn more.)

  The new feature isn't something that you couldn't do previously, if you knew how to code Input validation tests in JavaScript. But, like so many features in CF, the point is that a single tag can solve the problem for you much more easily.

  New Capabilities for Tags

  What's new is that the CFInput and CFTEXTInput tags, which are both used within a CFFORM tag, now offer the ability to validate their Input using Regular expressions. That means you're no longer limited to the validations built into the tags (such as date, time, telephone, zip code, credit card, Social Security number, etc.)

  If you're not familiar with these validations, they're quite useful (with some caveats). The CFInput tag, for instance, builds JavaScript for you that's sent to the browser to ensure that the user's Input for a given field matches an expected pattern for the chosen validation. You can read more about these tags in the CF docs or your favorite CF book (see Sidebar).

  Sidebar:

  Are you using the CF documentation?

  There are lots of great CF books on the market but did you know that CF comes with several very useful manuals? Often, the print version ends up on the shelf of the CF administrator rather than in the hands of CF programmers. If you can get the printed manuals (the set is also available for $50 from Macromedia), they're quite handy and include a reference manual as well as a programmer's guide and more.

  They're also available in HTML format by several means: first, they're installed within Studio (one way to reach them is to use the menu command Help>Open Help References Window). They may also be on your CF server (at http:// /CFDOCS/dochome.htm), though they shouldn't typically be installed on production servers for security reasons outlined in an Allaire Security Zone bulletin.

  The good news is that you can also now find them online at http://livedocs.allaire.com, a new service that also allows you to post comments on each page! Lastly, the docs are also available in PDF format at

  http://www.allaire.com/developer/documentation/coldfusion.cfm.

  Of course, the new capabilities are discussed only in the CF5 docs. If you have not yet installed CF5, you can view the documentation mentioned throughout this article by visiting http://livedocs.allaire.com. Also, if you install the new CF5 update for Studio 4.5.2

  (www.macromedia.com/software/coldfusion/resources/

  cf_tag_update/contents.html), it will install new help that appears as a new book in the Studio Help feature: "Cold-Fusion 5 (new manuals)."

  There's one potential source of confusion, however. While the update does offer new CF5 documentation that covers this new feature as well as new tag insight, tag completion, tag editors, and tag help for most CF5 tags and functions, the tag editor and tag insight features don't include these new attributes for CFInput and CFTEXTInput. The same is true in CF Studio 5 as of RC1. However, the features do work in CF5.

  Getting back to Input validation, the built-in validation available for CFInput and CFTEXTInput has always been somewhat limited (phone numbers had to include an area code, but you couldn't surround them in parentheses) or just nonexistent (there's no built-in validation for e-mail addresses, among other things).

  As of Release 5 of CF, you can now create any form of validation you want, if you know how to create the Regular expression to describe the pattern that the Input should follow. Want to validate Federal Employer Identification Numbers (FEINs, which are not the same format as SSNs)? You can. Want to let people enter phone numbers with or without area codes, and allow parentheses around the area code? You can.

  Validating an E-Mail Address

  Want to add an e-mail validation? You can do that, too. It's as easy as specifying that the validation will be using Regular expressions (using VALIDATE="Regular_expression") and then offering the expression in a new PATTERN attribute. Here's an example that will validate e-mail addresses:

 

  Email: Input TYPE="Text" NAME="email"

  VALIDATE="Regular_expression"

  PATTERN=" ^([_a-z0-9-]+(/.[_a-z0-9-]+)*@[a-z0-9-]+(/.[a-z0-9-]+)*/.

  (([a-z]{2,3})|(aero|coop|info|museum|name)))?$"

  MESSAGE="Email is improperly formatted">

  <Input TYPE="Submit">

 

  That Regular expression in the PATTERN attribute may seem quite daunting. For now, just accept that Regular expressions that do something useful may exist - and the cool thing is you can copy them from others to get the benefit.

  For example, I borrowed the e-mail matching pattern from one created by Jeff Guillaume for his IsEmail user-defined function offered at the www.CFLib.Org Web site. (If you're not aware of this great repository of user-defined functions run by CF mavens Ray Camden and Rob Brooks-Bilson, do check it out!)

  Note that the pattern isn't perfect: for instance, it won't catch if the user types somename@somedomain.om (leaving off the c in ".com"). The pattern does allow two or three character domain names (to allow for international domains like ".ca" and ".au".) What may surprise others is that last list of values (.aero, .coop, .info, .museum, .name). These are the newer top-level domain names that have been created recently by the InterNIC. There are still others, but they're either two or three characters.

  One other thing to note: it would be best to copy and paste this code rather than try to type it. Regular expressions are pretty picky, and if you get it wrong, you don't generally get an error mesage - the expression just fails to work as expected. For instance, the character used between "aero" and "coop" is a bar (|), not a lowercase letter L (l), nor the number one (1).

  How CFFORM Works

  I mentioned earlier that using CFInput within CFFORM would cause CF to build JavaScript that's sent to the browser on your behalf. That's the cool thing: you don't need to understand JavaScript or how to embed event handlers in your form; CF does it for you. If you want to see the code that's generated, use your browser's View Source or View Page Source menu command. The generated script is a little complicated, but it works and is compliant with all but the oldest browsers.

  If the user's Input fails whatever validation we've specified in the VALIDATE attribute (or now the optional PATTERN attribute), the form will not be submitted. The user will receive a JavaScript pop-up message (see Figure 1) telling them what's wrong. The message can either be a default one ("Error in fieldname text.") or one that you specify in the MESSAGE attribute, as I have in the example. The bottom line is that they won't be able to proceed past the form until the validated field passes muster.

  One of the things some people don't like about the CFInput VALIDATE attribute (both the older built-in validation and the new PATTERN-based one) is that users receive the prompt only when they submit the form. The JavaScript that CF builds isn't smart enough to detect the error when users leave the field. It also shows only one message at a time (rather than showing all validation failures at once). Finally, it isn't smart enough to leave the cursor on the field that contains the error users are being told about (which is all the more frustrating since it's only validating one at a time anyway).

  If these things really bother you (and they don't have to, if you're validating only a couple of fields), you should know that you can build your own validation to do those things, if you'd like. In fact, the CFInput tag offers an ONVALIDATE attribute, in which you name a JavaScript function (that you must write and include on the page) to do some specific validation. If you use this approach, any value in the VALIDATE (or PATTERN) attribute is ignored, but it does indeed give you greater control. Another alternative is the little known PASSTHROUGH attribute, which allows you to pass virtually any attribute/value pair you'd like (including one that uses JavaScript) to be made available on the generated Input tag.

  Still another thing that dissuades some people from using CFFORM is that they're afraid of its use of Java applets. It's important to clarify here that CFInput only uses JavaScript for validation - no Java applets. CFTEXT-Input, on the other hand, like several CFFORM subtags, does rely on a Java applet. The applet often provides enhanced control over the user interface (in fact, Release 5 of CF offers many new enhancements to these Java-enabled features), but using Java on the client does have its disadvantages, so some are afraid to use it.

  And despite what some may think, using CFFORM will not always cause the applet support files to load: they're loaded only when you use one of the applet-based subtags. But CFInput doesn't use Java - it uses JavaScript. Big difference.

  There is still another potential issue: not all browsers support JavaScript (and some users have it disabled intentionally for security concerns). Still, there's no harm in using this feature if JavaScript isn't enabled. The JavaScript built by CFInput is written in such a way that if the browser doesn't support JavaScript, it will simply be ignored.

  Of course, that means you shouldn't rely solely on the JavaScript validation since data coming from a browser that doesn't support it won't be validated. You need to also validate it on the server. A cool thing is that you can generally use these same JavaScript Regular expression patterns in the CFML code that processes the form, using them in the REFind or RE-FindNoCase functions. More about these in a moment.

  One last thing to note about our use of CFFORM in the preceding example: I used an empty string for the form's ACTION attribute value. CFFORM requires an ACTION attribute. It can't be left off, and even though in this particular example it doesn't really matter where we submit to, we have to provide one. Since we're only interested in observing the behavior when we try to submit it, I left the action blank so the page will just call itself. Of course, you should name the action page of whatever CF page will process the form.

  About Regular Expressions

  So how about that Regular expression? What does "^([_a-z0-9-]+(/.[_a-z0-9-]+)*@[a-z0-9-]+(/.[a-z0-9-]+)*/.(([a-z]{2,3})|(aero|coop|info|museum|name)))?$" mean? It may look a little confusing, but with a little knowledge, looking at a new pattern starts to make sense quite quickly. I can't offer a tutorial on Regular expressions, or regexps, as they're also known, in this article, but I can show you where to learn more.

  And what are regexps, anyway? They've actually been around for a long time and extend well beyond ColdFusion (and JavaScript). In fact, they're more strongly supported and more widely used in the UNIX operating system, but they've found their way into many more tools since they provide a powerful way to perform matching against a pattern, whether simple or complex. Obviously, the preceding pattern looks rather complex. There is even an entire book on the subject, called Mastering Regular Expressions, by Jeffrey E. Friedl (O'Reilly).

  The good news is that Macromedia has provided some bolstered documentation of them just for this specific new feature, in the second section of Chapter 9 ("Building Dynamic Forms") in the Developing ColdFusion Applications manual. The old name was Developing Web Applications with ColdFusion.

  The manual does have some coverage of regexps, as does the CFML Reference, but it's important to note that some of the coverage there is about ColdFusion's supported regexp syntax. What do I mean by that? It's another source of confusion.

  ColdFusion Regular Expressions?

  Prior to Release 5 (and still supported in CF5), there are several features in ColdFusion (and Cold-Fusion Studio) that leverage Regular expressions already. They include the REFind and REFindNoCase functions, as well as REReplace and REReplace NoCase. Each of these performs a find or replace (case sensitive or not), respectively, using regexps, as do the Extended Find and Extended Replace features in Studio (under the Search menu). The CFLDAP tag's FILTER attribute also uses them.

  These CF-enabled features, however, use a Regular expression syntax that Allaire built into ColdFusion. The syntax supported is indeed documented in the CF manuals. In CF5, it's the Developing ColdFusion Applications manual, Chapter 14, "Using Regular Expressions in Functions." In fact, this documentation is greatly improved over the documentation in previous releases (there was no similar chapter).

  Take note, however: this CF-specific version of Regular expressions isn't a complete rendering of Regular expressions as is used in UNIX or even JavaScript. And that's a key point for the purposes of this article: the Regular expressions used in CFInput's PATTERN attribute are JavaScript Regular expressions, passed verbatim to the client and interpreted on the browser.

  But they're similar enough, and as was mentioned, the new documentation does offer a brief rundown (in Chapter 9 of that book) of some typical JavaScript Regular expression syntax that might be used in the CFInput PATTERN attribute. The discussions are more complete in Chapter 14, and it's not too difficult to apply what's learned in one chapter to the equivalent features described in the other.

  So, I'll leave it to your exploration of the docs to learn what the Regular expression "^([_a-z0-9-]+(/.[_a-z0-9-]+)*@[a-z0-9-]+(/.[a-z0-9-]+)*/.(([a-z]{2,3})|(aero|coop|info|museum|name)))?$" used above means.

  Be sure to carefully test your use of Regular expressions in the environment in which you will deploy them. For the most part, if a regexp works in one browser, it will work in all of them. Note that the CF Regular expressions (used in the functions) offer a format called POSIX-compliant regexps. These should not be used in the CFInput PATTERN since they'll be passed down to the browser and my testing suggests they're not supported in JavaScript (at least they weren't in my Internet Explorer 5.5).

  Some Advanced RegExp Tips

  I'd like to add a couple of comments for the benefit of more experienced regexp developers. First, note that I have not used the opening and closing slash ("/") that you may be used to using to delineate an expression. That's because, if you look at the JavaScript created by CF, it's putting those in for you. If you add them as well, it will make the pattern fail. Forewarned is forearmed.

  Second, note that I've wrapped the entire pattern (other than the start/end characters, ^ and $) in parentheses. More important, I've followed that closing parenthesis with a "?". This is important as it indicates that the pattern being sought can occur either 0 or 1 time. If you leave that off, then you'll perhaps inadvertently indicate that an e-mail address is required. If none is entered, the pattern won't match and the validation will fail.

  You may indeed want to require that a value be entered, but there's an available REQUIRED attribute for the CFInput that will make it more clear to someone looking at your code that you're requiring an Input value. I just mention this because if you didn't think to add it (the ()? around the pattern), it would fail even if no value was entered and you may be quite confused by that. (Okay, if you're really experienced with regexps, maybe not!)

  Finally, keep in mind that in the case of both kinds of regexps (used in the CF functions or in CFInput's PATTERN attribute), it's certainly acceptable to use ColdFusion variables and other expressions to create the values to be used in the regexp. The CF expressions are interpreted by CF before the Regular expression is then interpreted, so you can use form and query variables, and so on, to help build your regexp.

  Validating Phone Numbers

  I mentioned at the opening that the built-in VALIDATE="telephone" is limited in some ways (forcing the user to provide an area code and not allowing parentheses around the area code). Here's a pattern that gets around those problems and still adds some other value:

  ^((/(?[1-9][0-9][0-9]/)?)?/s?[1-9][0-9][0-9]/s?/d{4})?$

  It, too, isn't perfect. It doesn't support international area codes, nor numbers formatted in other than the typical U.S. format for phone numbers of three-digit area codes, three-digit exchanges, and four remaining numbers. But while it does allow parentheses, dashes, and spaces, it doesn't require them. More experienced regexp users may wonder why I didn't just use "/d{3}" for the pattern to search for the three digits of the area code and exchange (the first three of the last seven numbers). The problem is that this wouldn't ensure they didn't start at zero, which is another rule for U.S. telephone numbers (for now, anyway).

  Closing Thoughts

  As I noted before, you don't need to understand these patterns in detail to benefit. Just go ahead and use them.

  Maybe eventually there will be a repository of patterns that can be used in a variety of ways, including the PATTERN attribute, the RE functions, Studio, and even more fancy user-defined functions, such as the IsEmail from which I got the example e-mail pattern.

  Better still, perhaps you'll be motivated to create other patterns to solve common problems, to offer to such a repository, or to simply solve your own challenges. I hope this quick tutorial on a new way to use them in CF5 motivates you to consider them, or at least be able to benefit from those who do.

  Additional Resources

  To learn more about adding your own validation, see Selene Bainum's article, "Extending CFFORM with Customized JavaScript Validation" (CFDJ, Vol. 2, issue 8) at www.sys-con.com/coldfusion/article.cfm?id=141.

  To learn more about JavaScript in general, see my article, "Getting Focus(ed)" (CFDJ, Vol. 2, issue 6) at www.sys-con.com/coldfusion/article.cfm?id=122.

  To learn more about doing form and Input validation with CF, see Kailasnath Awati and Mario Techera's article, "Some Thoughts on the Design of CF Data Input Applications" (CFDJ, Vol. 3, issue 3), at www.sys-con.com/coldfusion/article.cfm?id=234.

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

<script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>