10 Jan 1997

HTML "Forms"

When the Web was being initially designed, its predecessors (like Gopher) had minimal data entry and query capability. One could enter a name to lookup a phone number in the campus or corporate directory. Although HTML was primarily designed to format documents, it was related to other SGML-based systems with more elaborate dialog and data entry features.

The minimum set of GUI elements is well known. One finds versions of text entry fields, checkboxes, radio buttons, lists, and buttons in HyperCard, Visual Basic, and Java. HTML provides the same elements, but with an entirely different programming model.

In some languages, the application creates a sequence of objects when it runs. Each object represents some box or button in a Window visible to the user. The user then enters data, and the program extracts the results from the objects. In other systems, the programmer designs an entire panel, placing the boxes and buttons at specific locations.

A Web Form, however, is embedded within an HTML document which is either stored on disk or is generated dynamically by a program. However, the program that creates it ends as soon as the form is generated. The Browser displays the form, but the Browser contains no logic related to the form fields. When the form has been filled in, it is sent to a Server that usually loads a different program to receive the data. In no other Mac or Windows programming environment is the dialog or form completely isolated from the program that created it or the one that will process the results.

HTML Syntax

Enter your last name:

What type of coffee do you drink: Caffinated Decaf None.

Select a CPU chip:

(don't bother, this is just an example)

A form is an area of the document beginning with a <FORM> tag:

<FORM NAME="JOE" ACTION="/cgi-bin/javachip" METHOD="GET">
<P>Enter your last name:
<INPUT TYPE="text" MAXLENGTH="25" NAME="LASTNAME">
<P>What type of coffee do you drink:
<INPUT TYPE="radio" NAME="COFFEE" VALUE="CAF">
Caffinated
<INPUT TYPE="radio" NAME="COFFEE" VALUE="DECAF">
Decaf
<INPUT TYPE="radio" NAME="COFFEE" VALUE="NONE">
None.

Note: HTML doesn't care about case, and a value doesn't have to be in double quotes unless it contains blanks. So NAME="COFFEE" and name=COFFEE are the same. However, the case of values and attributes, whether they are or are not contained in quotes, is significant to languages like JavaScript.

The ACTION attribute of the FORM tag specifies the URL of a program that should be run to process the data entered. An <INPUT TYPE=TEXT> provides a one line simple text input box. TYPE=CHECKBOX or TYPE=RADIO provide other types of boxes and buttons. Each FORM field has a name and a value. The value of a text box is the data typed in it. The value of a check box is an indication whether it was checked or clear. A group of radio buttons share a common name, and the value indicates which button was selected.

Form Processing Programs

When the form is submitted, the Browser gathers the current values of every field and sends them to the Web Server along with the URL specified in the ACTION attribute. The Web Server loads the ACTION program, and the program processes the data. If METHOD=GET is specified, the FORM data is sent as a single long string (though it is limited to a total length of 255 characters). If METHOD=POST is specified, the FORM data is sent as separate lines of text and can be however long is needed to process everything. Obviously, METHOD=POST is more flexible and is the preferred option, unless the FORM is remarkably simple.

The Netscape and Microsoft Servers segregate application programs in their own dummy directories. For example, CGI programs are commonly referenced as "/cgi-bin/xxx". The server administrator will have configured "cgi-bin" to be an alias name that really points to some other directory somewhere on disk. For security reasons, the directories of programs will typically be separate from directories of HTML files or data. On a Netscape server, the directory alias name "server-java" is specifically reserved for server-side programs written in Java.

Microsoft Word in Office 97 provides direct support for adding form fields to a file. The Microsoft FrontPage Editor provides an even more powerful editing tool.

Forms and the Object Framework

To allow control through scripts and communication to other dynamic extensions, the modern Netscape and Microsoft Browsers create Objects from each Form elements. More generally,

The Browser is an application with one or more Windows.
Each Window has one or more Frames.
Each Frame has a Document.
Each Document can have one or more Forms.
Each Form can have one or more Fields.

Netscape decided to use the NAME attribute on the HTML tag to determine the name of the Object that it internally creates to represent the structure generated by the tag. In the previous example, <FORM NAME=JOE> generates a Form object with a name of "JOE". The first input field was <INPUT NAME=LASTNAME>, so JOE.LASTNAME is the Object for that field, and JOE.LASTNAME.value is the character string that the end user types into the input field.

This Object structure was first described as the environment for JavaScript programs in Netscape Navigator 2. Microsoft adopted the same object structure, with the same names and attributes. However, while the JavaScript interpreter is built into Netscape as a special case, Microsoft provides an OLE linkage from Internet Explorer 3 to any scripting language. Microsoft provides JavaScript and Visual Basic Script, while other projects are under way to support Perl and several other languages. OLE objects are also visible to programs written in C, C++, and Java (at least under the Microsoft J++ environment).

Netscape got a head start, but with its cross-platform development philosophy it could not become dependent on something like OLE that is available only within Windows. In Navigator 3.x, HTML objects are visible through the internal Netscape C/C++ library of support routines. That means that JavaScript sees them, and that Plug-In modules can both reference and expose Objects to the rest of the Browser. There was an initial stab at a Java Interface, but that has been revised. The current statement of direction holds that a future version of the Navigator will make these Objects visible to external programs through an industry-standard interface (CORBA). The implication is that Java Applets will use and generate Objects through the "JavaBeans" initiative and the extensions that will be part of JDK 1.1.

Now that Microsoft has delivered Internet Explorer 3 for both Windows and the Macintosh, with support on both platforms for OLE/ActiveX extensions, there may not be as much interest in waiting for Netscape. Open Systems are an important issue for Web Servers, but there are few organizations who regard a Unix client to be important enough to effect plans for application development.

Continue Back PCLT

Copyright 1996 PC Lube and Tune -- Distributed Applications and the Web H. Gilbert