JavaScript 101 - Part 3

In the first two parts of this introductory series on JavaScript, we explored the general elements that make up the language, and put them to some practical, if simple uses. The unfortunate reality of these examples, however, has been that they could all have been accomplished with straight HTML. Alternating table row colors can be created by hand, monthly revenue figures can be tallied in a spreadsheet and transcribed into HTML manually, and while JavaScript pop-up windows are nice in theory, they are by no means a necessity.

In this final instalment of this three-part series, we’ll put all of the concepts we’ve looked at so far to use towards a more realistic application of JavaScript: client-side form validation. In the process, we’ll explore a useful subset of the Document Object Model (DOM) related to forms and form elements, and learn about a new event handler. By the end of this article, you should have a well-rounded knowledge of the basics of JavaScript, and be prepared to apply the techniques presented here to your next Web design project, or to tackle more advanced topics such as Dynamic HTML (DHTML).

Client-Side Form Validation

A common adage among experience programmers is “always assume the user will type in nonsense.” Basically what this means is that, while your program (or Web page) might be intended to take in some reasonable user input and produce a reasonable output, you should also allow for the fact that the user input may be nothing more than random characters, and that your program should still produce reasonable output! How frustrated would you be, for instance, if every time you typed in an incorrect URL, your Web browser crashed? I think very!

Fortunately for Web programmers like you and I, most user interaction comes in the form of clicked links, and since it’s pretty difficult for someone to click a link ‘wrong,’ incorrect user input is not something we have to deal with much. Pretty much the only place where this is an issue is when we ask a user to fill in a form. For instance, if you were to create a page where users of some software product could register for technical support, you might have form fields for their name, address, phone number, email address, and other pertinent details. Instead of typing his or her name, however, a user could just as easily leave the field blank. Instead of his or her phone number, the user might type “none of your business.” And instead of a valid email address the user could type any number of things. This last value is especially problematic, because you might have an automated process that sends technical support announcements to registered users, and if an invalid email address makes it onto that list, it could interfere with the process of sending these announcements to other users who filled in the form properly!

The easiest solution to all of these problems is to check if the user has typed sensible values into the form fields before accepting the submission for processing. There are two places where this validation can happen: on the client or on the server.

In the old days, whichever program on the Web server (e.g. a CGI Script) received and processed the form submission would first have to check the submitted data to make sure that it was valid. If it was found to be incorrect in some way, the program wouldn't process the submission, and instead would send a Web page back to the browser that explained the problem (e.g. “Sorry. One or more required fields were not filled in.”). Since the validation occurs on the Web server in this case, this set-up is generally referred to as server-side form validation. While it has the advantages of being simple and reliable, server-side validation can be annoyingly slow, because the user must wait for the form submission to make its way to the server and for the response page to return only to discover that (say) he mistyped his phone number.

Instead, some JavaScript can be included in the Web page with the form, which instantly verifies the data entered into the form, and prevents the form submission from going forward if there is something wrong with the information to be submitted. As we’ll see, JavaScript also allows for the added flexibility of pointing out exactly where the mistake occurred by moving the user’s cursor to the problem field so that it can be fixed immediately. Since JavaScript runs on the Web browser (the client), this type of validation is called client-side form validation. It is this type of validation that will be the focus of this article.

One final note before we get into the details: since JavaScript can easily be disabled on all Web browsers in current service, and since some older Web browsers don’t even support JavaScript, client-side form validation is best used as a complement to server-side validation – not a replacement. JavaScript validation is, essentially, a ‘first line of defence’ against incorrect form submissions. If somehow an incorrect submission makes it to your server-side program, it should still be able to handle the submission gracefully.