8.0 Introduction

Giving scripted intelligence to web forms was the impetus that led to the development of the JavaScript language and the notion of a document object model. While a lot has happened to scripting in the meantime, forms still make frequent use of scripts to assist with user-friendly instantaneous interaction that otherwise requires a two-way trip to the server (and delays for the user) to accomplish.

Because of the comparatively long history of scriptable forms and form controls, it is comforting to know that most such scripts work with a wide range of browsers, and not just those that implement the W3C DOM. Even so, there are some misunderstandings about the combination of scripts and forms that I'll attempt to clear up in this chapter.

8.0.1 Referencing Forms and Controls

Before the W3C DOM, scripts used what is now known as DOM Level 0 syntax to reference form objects and the form controls (input and textarea elements) within them. This long-time convention relies for the most part on the form and controls having name attributes assigned to them. In fact, even today's browsers won't submit form control values to the server unless the elements have names assigned to them (independent of the now ubiquitous id attribute). At the same time, however, the object model provides arrays of forms and form elements, which can be accessed through JavaScript array syntax and numerical index values. For example, if a document contains a single form whose name is userInfo, backward-compatible scripts can reference the form object in any of the following ways:

document.forms[0]
document.forms["userInfo"]
document.userInfo

Each form element object also contains an elements array that contains references to all of the recognized form controls nested inside the frame. For example, if the second input element of the userInfo form is a text box named age, you have three ways to reference that text box for each of the three ways you can use to reference the containing form. Using just one containing form reference, here is an example of three equivalent references to the age text box:

document.userInfo.elements[1]
document.userInfo.elements["age"]
document.userInfo.age

Notice how this syntax follows the element containment hierarchy: document to form to control. This allows for the possibility of a form control's name being reused in multiple forms on the page—something not possible (or at least not encouraged) with id attributes.

In browsers supporting scriptable id attributes of elements (IE 4 or later and NN 6 or later), you can also reference a form directly by way of the object model syntax(es) supported by the browser. For example, in IE 4 and later, you can use the Microsoft DOM reference syntax:

document.all.formID
document.all.formControlID

For W3C DOM syntax (IE 5 or later and NN 6 or later), use the regular element-referencing syntax:

document.getElementById("formID")
document.getElementById("formControlID")

Even though your scripts can use only the ID to build references, you'll want to assign an identifier to both the name and id attributes of each element if the form is to be submitted to the server. You can use the same identifier for both attributes of an element and not risk collisions.

Browser versions that you need to support with your scripts should dictate the syntax you use to address forms and controls. If backward-compatibility is of any concern with your audience (including Navigator 4), stick with the DOM Level 0 syntax. It will continue to be supported in new mainstream browsers for a long time to come.

8.0.2 Form Validation Strategies

Client-side form validation is a helpful service that speeds the correction of potential errors in forms before they ever reach the server. That is not meant to imply that client-side validation can replace server-side validation. Far from it. But, like most DHTML applications, client-side validation helps your users be more efficient when filling out complex forms.

Even on the client, however, you have two types of validation strategies to consider: real-time and batch mode. In real-time validation, a script looks for signs of activity—such as onchange events in text boxes—to immediately validate an entry against whatever data restrictions apply to the field. The advantage of instantaneous validation feedback is that the user's mind is still fresh about the information filled into a field. In other words, when the user has just entered an address into an email address field, it's more helpful to bring the user immediately back to that field and correct the error, rather than wait until later. On the other hand, in most situations, you should not be so dogmatic as to absolutely require that a form be filled out in order, which can happen when you use onblur events to trigger validation. Give the user a chance to tab through and skip over a text box while filling out a form.

But then be sure to catch any missed or passed text boxes with a batch validation right before the form gets submitted. This offers a last-chance review of data before sending it to the server. In most cases, the same routines you use for the real-time field checking can be reused by the batch validation routines triggered either by the onsubmit event of the form object or by a regular button-type input element that invokes validation routines and form submission.

Additionally, you will have to decide whether your text box inspections will use old-fashioned string parsing or the more modern regular expression facilities of JavaScript. Regular expressions provide powerful and quick ways of looking for patterns in a text box entry, but the syntax for using regular expressions is rather terse and cryptic. You will see some examples of both forms in Recipe 8.2, and the introduction to Chapter 1 presents a brief overview of regular expressions in JavaScript, but you'll need a solid JavaScript tutorial or reference to understand the full scope of regular expressions.

8.0.3 Email Submissions and Return Pages

A traditional HTML form submits its data to a program running on the server. That program can be in a variety of languages (Perl, Java, Visual Basic, C, C++, C#, Tcl, and more), but the client never knows or cares what happens on the server. In typical operation, the server program receives the data, tears it apart, stuffs it into database tables, or otherwise manipulates the data for storage on the server. When the data is processed correctly, the server then returns an HTML page back to the client. By default, that return page displays in the same window or frame as the form. There's nothing particularly special about this transaction.

But many scripters don't have access to server scripting, either because they host on closed systems, or the technology is beyond their field of expertise. To fill in the gap and still capture the data submitted by a form, they have resorted to assigning a mailto: URL to the action attribute of a form element. When this approach first appeared in browsers, the form's data was quietly emailed to the address assigned to the mailto: URL. But as security consciousness overtook the Web (especially with the advent of scripting), such surreptitious emailing came to an end. Instead, a more explicit email process took hold, whereby the user with a properly configured browser and email client sees the email message before it is sent.

A problem with this scenario is that a significant number of users either don't have their email clients configured correctly and matched to their browser, or they are intimidated by the appearance of the email window. The result is that using a mailto: URL to submit forms is less likely to capture all submissions that you might otherwise receive.

However, should you persist with your usage of the mailto: URL, be aware that this kind of submission does not return any kind of page to the browser. There is no confirmation that the mail was submitted correctly or completely. Moreover, there is no absolutely reliable way to script a dummy confirmation page. To do so reliably requires that the browser receive some notification of completion so that the page could be displayed in place of the form's page. If you or a script removes the form's page before the actual submission completes its task, the submission may be aborted on the network—losing even more potential submissions before they reach you.

The solution is to search the Web for a third-party host for a Unix program called FormMail. This program lets you submit a form to a genuine server program that forwards the content to a mail address you supply in the setup process.