How Not to Script HTML Form Validation

Douglas Crockford has dubbed Javascript “the world’s most misunderstood programming language.” If he is correct, and I believe he is, then it should be no surprise that a good deal of Javascript development is tainted by “AntiPatterns”.

An AntiPattern quite simply is what does not work. Let’s consider what this means on a couple of different levels, within the context of validating form data with Javascript.

First lets consider specific code that “does not work”. Recent books have gotten better at avoiding the following sort of thing, but it remains widespread to this day (to keep this example as brief as possible I’m not including any code that would provide feedback to the user, such as a Javascript alert).

<form
onsubmit= ‘return this.fname.value != “” &amp;&amp; this.lname.value !=””‘>
First Name: <input type=”text” name=”fname”>
<br>
Last Name: <input type=”password” name=”lname”>
<br>
<input type=”submit” value=”Log In”>
</form>




If the user enters absolutely nothing into either fname or lname, the form’s onsubmit handler will return false and the form will not be submitted. The code successfully prevents submitting completely empty fields.

It does not however prevent the user from entering spaces into those fields. It is therefore not enough to test against the empty string “”.

The solution is to test against a “regular expression” object. For the uninitiated, “regex”’s, as they are also sometimes called, represent a pattern of characters. For the task at hand, we are going to use a very simple pattern: /\S/

The first thing to notice are the beginning and ending slashes. These simply signify that what’s between them is the expression, not unlike quotation marks signifying that they contain text.

Within the slashes, the pattern \S stands for any non-whitespace character. Regular expressions in Javascript have some useful built in methods, including test() , which returns true or false depending on whether a string passed as an argument matches the pattern.

So in the above example we can just switch the onsubmit event handler to the following, and it will not only reject completely empty fields, but also fields containing only whitespace, such as spaces:

onsubmit=’return /\S/.test(this.fname.value) &amp;&amp; /\S/.test(this.lname.value)’

Substituting the above, now both name fields must contain some non-whitespace characters in order for the form to get submitted. Following the colorful parlance for AntiPatterns, the erroneous example on page 1 might be called the “Out of Sight Out of Mind” AntiPattern. Except that AntiPatterns typically describe a problem that is more systemic, rather than one that can be so readily rectified by correcting one line of code. For instance, failure — or refusal — to use a language feature such as Regular Expressions.

Better yet exemplifying a bona fide AntiPattern in a Javascript form validation context is what I call the “All Web Development is New Development” fallacy. This antiPattern, like the code defect debunked in the first example, is commonplace both in books and in code libraries distributed all over the web.

“All Web Development is New Development” in the Javascript form validation context most often occurs through the suggestion that, to signify that form fields are required to be filled in, these required fields must be named in a certain manner. Users of such code are instructed to do such things as end the names of their form fields with “_req” .

So, in our first example, “fname” would become “fname_req” , and “lname” would become “lname_req” . To begin with, though, this violates one of Arthur J Riel’s Object-Oriented Design Heuristics, particularly 3.5, which states in part: “In applications which consist of an object-oriented model interacting with a user interface, the model should never be dependent on the interface.”

The HTML comprises the user interface. Now substitute “data” for “model” above. Data is required to specify one field as required, and another as not required. But by appending “_req” to the name of an HTML form element, the data becomes dependent on the interface.

Rules are made to be broken, but not in this instance. Because, although requiring that form field names have “_req” be appended to them might work in the case of a new web application, what about an existing web application? It almost certainly consists in part of server-side form processing code that relies on pre-determined form field names. Adding “_req” to those field names will almost certainly cause existing server-side code to malfunction.

About the Author: George Jempty
Born on Long Island in 1963. Learned to program in Junior High using the orange book “Basic Basic”. Two careers prior to IT were Food Service and Market Research. First exposure to enterprise development came as “Fielding” (Data Collection) Director for a successful market research start-up in the early 90’s. IT professional since 1998. Have contracted for or been employed by several nationally and internationally recognized corporations. Specialities include database and web development.