Chapter 11

HTML Forms


CONTENTS

The most commonly used container for structured data is the paper form. Forms permeate our lives as social beings, from a birth certificate to school report cards, from 1040 forms and mortgage applications to requests for social security.

Small wonder, then, that forms are the bedrock of user interaction on an Intranet. The ease with which HTML forms-sometimes called fill-in forms-can be created is one of the technology's big benefits, for users and developers alike.

HTML forms provide a rich set of data input features that emulate those found on common paper forms. For instance, a form can be used to capture manually-entered information to a database. A related application is the use of forms to input free text, such as a discussion forum message.

Web-based forms do have an important limitation, though: You have to submit them to validate their data. This compares unfavorably with client/sever applications developed using PowerBuilder or Visual Basic, which can do on-the-fly validation based on built-in business logic.

Fortunately, scripting languages such as JavaScript are beginning to make it possible to build Web pages that do everything a client/server application can do. The downside is that such pages are no longer simple to develop and maintain, sacrificing much of what makes an Intranet attractive in the first place.

Later chapters cover the use of CGI scripts to process forms and connect them to legacy applications.

In this chapter, you learn:

Forms Tags

Forms elements make up a significant part of HyperText Markup Language. This section covers the use of HTML tags to create forms. Also discussed are the methods available for submitting forms to a server for interpretation and processing.

The set of tags useful for designing forms is listed in Table 11.1.

Table 11.1  HTML Tags for Building Forms
TagBrief Description
<FORM>…</FORM>Begins and ends an HTML form within a Web page.
<INPUT>Inserts a variable field such as a button, checkbox; or text box.
<SELECT>…<SELECT>Creates a scrolling list box of options for user selection.
<OPTION>Specifies values for a list box created with <SELECT>.
<TEXTAREA>…</TEXTAREA> Creates a scrolling box where users can enter free text, such as comments.

Figure 11.1 shows a simple form composed of these elements.

Figure 11.1 : Sample Intranet form showing how INPUT, SELECT/OPTION and TEXTAREA tags display in Netscape Navigator.

Using the Forms Elements

NOTE
NCSA's primer on HTML forms support is one of several handy online guides. You'll find it at http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html.

This section walks you through the form tags, giving a short code example of each to show how it's done. The examples are on the accompanying CD-ROM. Feel free to use them as a springboard for your own HTML forms.

NOTE
The sample code is typical in that much of the HTML serves a cosmetic purpose. Users are accustomed to paper forms with neatly aligned fields; it's a good idea to mimic this online. Two techniques can help.
The technique used here is to set off the form code in a <PRE></PRE> tag pair. This causes the browser to display text, tabs and spaces in a fixed-width font. Designers can use the uniform length of such features to line up the elements in a form.
Another technique is to place form elements in the cells of an HTML table. Table layouts are more complex than preformatting, but provide greater design versatility.

Element: <FORM>…</FORM>

This pair of tags sets off an HTML form. Other elements, such as text areas and check boxes, must be contained in a FORM tag pair. The FORM tag takes three attributes, which specify the action to be taken when the form is submitted. Discussion of FORM attributes is postponed to the next section.

Element: <INPUT>

This tag displays an input element such as a text field, checkbox, or radio button (see figure 10.2). Together these elements are called editable fields, because they can be altered by users.

Figure 11.2 : Web form showing various types of INPUT: checkbox, radio button, password, text, submit, and reset. The HTML code is given below.

The syntax for INPUT is illustrated in the code for figure 11.2, shown below in Listing 11.1.


Listing 11.1  HTML code for implementing the form shown in figure 11.2
<FORM METHOD="POST" ACTION="/cgi-bin/vform">
<CENTER>
<TABLE WIDTH=75% CELLPADDING=8 BORDER=2>
<TR>
     <TD ALIGN="center" COLSPAN=5><IMG HSPACE=6 SRC="pix/y2_new.gif"  ALT="New!">
     <FONT SIZE=+1>T</FONT>RAVEL PLANNING SERVICE</TD>
</TR>
<TR>
     <TD ALIGN="left" COLSPAN=2>
     What brochures would you like?<BR>
     (Check all that apply)
     <BLOCKQUOTE>
       <INPUT NAME="VacLoc" TYPE="CHECKBOX" VALUE="Bahamas"> Bahamas<BR>
       <INPUT NAME="VacLoc" TYPE="CHECKBOX" VALUE="Honolulu">  Honolulu<BR>
       <INPUT NAME="VacLoc" TYPE="CHECKBOX" VALUE="Las Vegas"> Las  Vegas<BR>
       <INPUT NAME="VacLoc" TYPE="CHECKBOX" VALUE="Hoboken"> Hoboken<BR>
     </BLOCKQUOTE>
     </TD>
     <TD VALIGN="top" ALIGN="right" COLSPAN=3>
     <PRE>
     Username: <INPUT NAME="Username" TYPE="TEXT" ROWS=1 MAXLENGTH=10  SIZE="10">
     Password: <INPUT NAME="Password" TYPE="PASSWORD" ROWS=1  MAXLENGTH=10 SIZE="10">
     </PRE>
     </TD>
</TR>
<TR ALIGN="center"><!-- Bottom Line -->
     <TD WIDTH=28%>Weeks of Vacation:</TD>
     <TD WIDTH=18%><INPUT NAME="VacWks" TYPE="RADIO" VALUE="1"> 1</TD>
     <TD WIDTH=18%><INPUT NAME="VacWks" TYPE="RADIO" VALUE="2"> 2</TD>
     <TD WIDTH=18%><INPUT NAME="VacWks" TYPE="RADIO" VALUE="3"> 3</TD>
     <TD WIDTH=18%><INPUT NAME="VacWks" TYPE="RADIO" VALUE="4"> 4</TD>
</TR>
</TABLE>
<INPUT TYPE="submit" VALUE="Send This Request"> <INPUT TYPE="reset"  VALUE="Clear Form">
</CENTER>
</FORM>


Each INPUT statement has a name and a type attribute. The name is the variable name associated with input data, which in turn is captured as the value in a name/value pair.

Type must be one of following:

Input typeDescription
checkboxThis multiple choice element behaves much as its paper equivalent. Checkboxes are off by default, but the CHECKED attribute can be used to turn them on. When a checkbox is on, the associated name/value pair is submitted with the form.
Multiple checkboxes with the same NAME can be used to select several values at once. For example:
Hobbies (check all that apply):
<INPUT TYPE="checkbox" NAME="hobby" value="computers">
<INPUT TYPE="checkbox" NAME="hobby" value="movies">
<INPUT TYPE="checkbox" NAME="hobby" value="reading">
<INPUT TYPE="checkbox" NAME="hobby" value="sports">
radioRadio buttons, like checkboxes, are a multiple choice input element, but radio choices are mutually exclusive. The buttons in a group must have the same NAME. Turning one button in a group on turns the other buttons off.
The following example assigns the value of the selected button to the variable EmpYrs:
<INPUT TYPE="RADIO" NAME="EmpYrs" VALUE="0" CHECKED> 0-4
<INPUT TYPE="RADIO" NAME="EmpYrs" VALUE="5"> 5-9
<INPUT TYPE="RADIO" NAME="EmpYrs" VALUE="10"> 10-14
<INPUT TYPE="RADIO" NAME="EmpYrs" VALUE="15"> 15+
textA line of text. The width of the displayed input field can be set by the SIZE element.
Text fields take an optional attribute, MAXLENGTH, which specifies the size in bytes of the input buffer. Without MAXLENGTH the buffer is unlimited.
Example:
<INPUT TYPE="text" SIZE=36 MAXLENGTH=128 >
hiddenThis tag prevents an INPUT element from being displayed. Any VALUE information is still submitted with the form.
The reason for using hidden is to keep track of the state of an interaction. HTTP is normally stateless, meaning it has no memory of prior exchanges during a session. Hidden fields can be used in a script-generated form to convey the state of a transaction.
For instance, to give a user three tries in a guessing game, you might use a hidden field to keep track of past tries:
<INPUT TYPE="hidden" NAME="try" VALUE="2">
passwordThis INPUT type is identical to text, except that characters typed into the field are echoed password-style, as asterisks or whitespace.
Note that this protects the user's password at the client only, since all form data (including INPUT TYPE="password") is sent over the Web as plain text.
reset This INPUT tag places a button on the form which, when pressed, clears all values entered by the user and restores the defaults.
Like submit, the button can be labeled using the VALUE attribute:
<INPUT TYPE="reset" VALUE="Clear Form">
submitThis INPUT tag places a button on the form which, when pressed, sends all form data as name/value pairs to the URL specified by the FORM action tag.
Like reset, the button can be labeled using the VALUE attribute. Example:
<INPUT TYPE="submit" VALUE="Send Form">

Element: <SELECT>…<SELECT>

Element: <OPTION>

This tag pair can contain a set of options presented to the user as a scrolling list from which one or more items can be selected. Each item is specified by an <OPTION> element. Figure 11.3 shows a typical use of the SELECT statement to implement a user survey.

Figure 11.3 : Web form showing variations of the SELECT/OPTION tag pair. The HTML code is shown in Listing 11.2.


Listing 11.2  HTML code for implementing the form shown in figure 11.3
<HTML>
<HEAD>
     <TITLE>HTML Forms: SELECT tag</TITLE>
     <!-- To see what this code looks like, refer to 
     Figure 10.3 in *Running a Perfect Intranet* -->
</HEAD>

<BODY>
<H1>Cultural Survey</H1>
<HR WIDTH=50% ALIGN="left" SIZE=4>
<BASEFONT SIZE=4>

<!-- Note: HTML Form Begins Here-->
<FORM METHOD="POST" ACTION="/cgi-bin/vform">
<PRE>
<B>What type of music do you like?</B>	     <SELECT  NAME="FavoriteMusic" SIZE=5 MULTIPLE>
<OPTION>Blues
<OPTION>Hip-Hop
<OPTION>Jazz
<OPTION>Polka
<OPTION>Reggae
<OPTION>Waltz
</SELECT>

<B>What type of art do you like?	</B>  <SELECT NAME="FavoriteArt"  SIZE=4 MULTIPLE>
<OPTION>Cave
<OPTION>Medieval
<OPTION>Neo-Realism
<OPTION>Dada
<OPTION>Cubism
</SELECT>

<B>What type of books do you like?</B>	    <SELECT  NAME="FavoriteBook" SIZE=1>
<OPTION>Biography
<OPTION>Computer
<OPTION>Mystery
<OPTION>Poetry
<OPTION>Romance
<OPTION>Sci-Fi
</SELECT>
</PRE>
<INPUT TYPE="submit" VALUE="Submit"> <INPUT TYPE="reset"  VALUE="Clear">
</FORM>

<HR WIDTH=50% ALIGN="left" SIZE=4>
<H5><I>Contact <A HREF="mailto:gbenett@shore.net">webmaster</A></I></ H5>
</BODY>
</HTML>


SELECT takes three attributes:

AttributeWhat it does…
MULTIPLEEnables users to select more than one item from a SELECT list, usually by holding down a key while selecting. Absent MULTIPLE, only one item can be selected.In the example of figure 11.3, the music and art lists use MULTIPLE, while the book list does not.
NAME(required)Specifies the variable name assigned to the submitted value.
SIZESpecifies the number of text lines displayed in the SELECT list, which typically appears as a scrollbox. In figure 11.3 the music and art lists are scrollboxes with SIZE > 1, while the book list is a pull-down menu of SIZE=1.

Element: TEXTAREA…</TEXTAREA>

TEXTAREA creates a scrolling box where users can enter free text. Any text placed between the opening and closing tags appears in the TEXTAREA as an initial value. In the Vacation Request Form example of figure 11.1, a TEXTAREA is used to get employees' date preferences.

TEXTAREA takes three attributes (which must be present):

AttributeWhat it does…
COLSSpecifies the width of the text entry area in columns.
NAMESpecifies the variable name assigned to submitted text.
ROWSSpecifies the height of the text entry area in rows.

HTTP Methods for Submitting Data

NOTE
For a technical discussion of the client/server exchange kicked off when you submit a Web form, see the tutorial hosted by the University of Kansas at http://kuhttp.cc.ukans.edu/info/forms/formsintro.html.

The few simple elements presented in the last section account for all the power of HTML forms. They enable you to create powerful data entry (or query) screens with only a few lines of code.

Form data is processed on a Web server. To send the filled-out form from her browser to the server, a user clicks the form's SUBMIT button-an INPUT element of TYPE="submit".

Earlier in the chapter we noted that the FORM element takes three attributes. These determine where, and by what HTTP method, the form is shipped for processing. The attributes of FORM are given below.

AttributeWhat it does…
ACTION(required)Specifies the URL to which FORM content is to be sent for processing. This is usually the address of a script or mailto target.
Example:
<FORM ACTION="mailto:g.benett@ieee.org">
METHODHTTP provides several methods for clients to request service: GET, POST, PUT, HEAD. By far the most prevalent in GET, which gets an object from the server, and POST, which posts data to an object on the server. As a rule of thumb, use POST when passing form data to a program, and GET when making a request or performing a search.
Examples:
<FORM ACTION="http://www.que.com/cgi-bin/readform" METHOD=POST>
<FORM ACTION="http://www.que.com/cgi-bin/locate?G+Benett"  METHOD=GET>
ENCTYPEIf present, this optional attribute specifies the MIME type used to encode data exchanged with the POST method. At present only one value is allowed (URL-encoding):
application/x-www-form-urlencoded

Protocols for writing forms-processing scripts are well-established. We discuss them in the next chapter. The remainder of this chapter focuses on the use of forms on an Intranet.

Forms for Intranet Applications

NOTE
The tutorial How to do Forms, at www2.ncsu.edu/bae/people/faculty/walker/hotlist/forms.html, features many examples of scripts you can adapt to process your own forms.

The Vacation Request Form used as an example earlier in the chapter represents one way forms can add value on an Intranet. Rather than sending a paper form to employees via interoffice mail, a Human Resources department might develop an HTML form such as the one in figure 11.1. Such a form would have a shorter turnaround time than paper, eliminating a round-trip mailing. Moreover, an electronic form can feed database applications directly, without error-prone rekeying.

This type of forms-based application replaces one or more paper forms. Another class of application for HTML forms is collaborative. Forms make a convenient front-end to discussion forums, a text-based medium useful for engaging in dialogue at a distance. Workgroups and departments can often reduce time spent traveling to meetings by exchanging ideas on the Intranet.

Additional uses for HTML forms are described later in the book.

Replacing Paper Flows

Any business process that relies on the exchange of paper forms is a candidate for improvement via an internal Web. One of the first successful projects in this area was the Enterprisewide-information Viewing Environment (EVE), developed in 1995 at Sandia National Labs, Albuquerque, New Mexico.

EVE is a forms-based suite of productivity applications that includes:

What features do these applications share that make them suitable for implementation on an Intranet? For one thing, they enable queries against corporate databases to take place from the desktop. For another, applications like SAND Reports shift the traditional "push model" of disseminating documents everywhere to a more effective "pull model" in which only interested parties receive data. EVE applications share a common foundation in TCP/IP and HTTP, as well-the hallmark of an Intranet.

Distributing interactive documents using a Web lends itself naturally to workflow automation. This class of applications unites e-mail, forms processing, and security tools such as digital signatures to streamline paper-driven business processes.

Formerly the province of vertical application suites or proprietary groupware such as Notes, workflow software is enjoying new popularity on corporate Intranets. Web browsers with integrated SMTP mail and digital certificates make a familiar, cost-effective front end for the software. If today's Web server technology lacks strength as a workflow engine, products like Livelink Intranet from Open Text Corporation are filling this gap. Figure 11.4 shows a screen from a workflow demonstration on the Open Text Web site.

Figure 11.4 : Sample workflow automation screen using Livelink Intranet. Note the integration of forms and tabular information to show project status. (Courtesy: Open Text Corp.)

NOTE
For more information on Livelink Intranet, visit Open Text's Web site at http://www.opentext.com/.

Forms for Collaboration and Control

One of the straightforward uses for forms on an Intranet is as a standardized means of data entry. HTML forms designed to mimic their paper counterparts fall in this category. Forms can also be used to carry on written dialogues between users. While this is similar to an e-mail exchange, it has unique features that may be advantageous for some communications. Messages appear in a public forum, for instance, visible to all users or a special-interest workgroup. The precise sequence of original messages and replies is concisely displayed. And the dialogues are captured for posterity in a format easily tapped as a knowledge base.

In addition, forms can be used to extend the forum concept in novel ways. One example is to let users create their own Web pages. This amounts to allowing HTML tags to be entered in forum messages. Besides opening the medium of exchange to include images and hypertext, this can be a handy technique for updating the content of standard Web pages. Webmasters and users alike can benefit from this distribution of tasks. Users might enter new material on forms provided expressly for that purpose. The target script would validate the content and, perhaps, install it in the appropriate place on a Web page.

Forms can also be used for control. Numerical data can be processed and exported by the Web server in a form appropriate to device or process control. For instance, on the Edime‰ family of Web Servers for Netware, the server's serial ports can be controlled by special HTML instructions.

Interesting uses of HTML forms for control include positioning surveillance cameras, remote operation of HVAC (Heating, Ventilating and Air Conditioning) equipment, fax-on-demand of digitized documents, text-to-speech conversion, and network management.

NOTE
If you're considering the use of HTML forms for control, keep in mind that Intranet messaging, like all TCP/IP communications, uses statistical media access techniques. You can't know whether a control action will execute in one second or one minute. Web forms can offer real benefits where timing isn't critical, but for real-time process control, stick with a deterministic system.

Much as happened with PC's, character-based user interfaces will give way to graphical controls as applet technology matures. Libraries of JavaScript and ActiveX "widgets"-autonomous graphic control elements-have already begun to appear for the Web. A year from now, expect to turn a dial rather than enter a numerical temperature to control your Web-based thermostat.

Limitations of HTML Forms

If Web-based forms are so powerful, won't they eventually replace other types of software interface, such as graphical screens created with PowerBuilder and Visual Basic? Eventually, maybe, but not any time soon.

HTTP transactions have some key drawbacks that guarantee stand-alone GUI applications a future. These drawbacks issue from two aspects of the protocol:

The fact that HTTP transactions don't keep track of state means that each current activity is unaware of prior transactions. Put simply, Web work has no memory. This makes it difficult to keep track of a user's path through a Web site, for instance.

Various artifices exist to get around the Web's inherent statelessness. Forms can be generated on-the-fly, for instance, recording state in "hidden" INPUT tags. Netscape developed another technique called "cookies" (now supported by Microsoft as well) in which state information is written to the client's disk. This has an advantage over form-embedded state, in that it can survive the session. Using cookies, a server can resume a state-specific dialogue several hours, or days, later. A disadvantage of cookies is that any process that surreptitiously writes to the client's disk poses a security hazard.

In any case, the absence of state memory from native HTTP limits the technology's use for robust transaction processing.

The other limiting factor is the single-item nature of HTTP connections. This accounts, among other things, for the confusing disparity between hits and visits in server logs. Each file component of a Web page is transferred (and logged) in a separate connection. A more serious consequence of single-item transfers, at least from the standpoint of forms, is the fact that Web connections are opened and closed for each transfer.

This means that a Web server remains unaware of any dialogue with a client until the client submits the form. Many niceties of the modern graphical interface are lost as a consequence. For instance, the server has no knowledge of, and therefore can't validate, data entered by the user. Compared to a typical GUI application, in which later fields are automatically prefilled as the user completes earlier ones, Web forms are quaint in this regard. The ritual of submitting only complete forms, only to have them rejected when the server finds an error, recalls the days of programs submitted whole on keypunch cards to a data center. Applications that enable incremental data transfers by leaving the client/server connection open have a clear advantage in this regard.

The ultimate workaround for both statelessness and single-item connections is to bring HTTP up to the level of other client/server protocols. This might happen in a couple of ways. HTTP might itself be extended as an Internet standard. Another, superior protocol (possibly proprietary) might replace HTTP altogether. Or, modular extensions to HTTP might appear that provide the missing functionality.

In fact this third option corresponds to the rise of scripting subsystems such as JavaScript and VBScript, and of server-side Java applets as well. These innovations fill many gaps in early Web functionality. They are discussed in the next chapter. It may be worth remarking that much of an Intranet's initial appeal comes from its simplicity and cost-effectiveness. Extending the technology with complex object-oriented languages may, or may not, preserve these attractive benefits. If nothing else, it makes deciding between a pure Web-based solution and a hybrid of Web and non-Web client/server applications much more interesting.