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:

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 pagesomething 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:

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 activitysuch as onchange
events in text boxesto 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
networklosing 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.