onsubmit= ‘return this.fname.value != “” && this.lname.value !=””‘>
First Name: <input type=”text” name=”fname”>
Last Name: <input type=”password” name=”lname”>
<input type=”submit” value=”Log In”>
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.
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) && /\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.
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.