However, this hypertext interface on its own has its limitations. It is still essentially a one-way communications medium, with producers on one side and consumers on the other. To be an effective business communications tool, there's a need for interaction. There's also a need to provide dynamically obtained, up-to-date information, rather than just static pages of hypertext. Fortunately, the web has evolved to meet these needs, with extensions such as fill-out forms, server-side processing, and most recently, client-side programming capabilities.
<FORM METHOD="POST" ACTION="URL for CGI program"> ... form input fields ... </FORM>A form in HTML is enclosed within
FORMtags. On the opening tag, we specify an
ACTION, with is usually the URL to invoke a CGI program on the server, which will process the form input data. We also specify a
POST, which indicates the way the form input is to be passed along to the server. (We normally use
POSTfor any forms that will contain a fair amount of data;
GETcan be used for simple queries, where the amount of data is small.)
Since we'll only get to CGI programs in part 2,
we'll use a different type of
ACTION for testing our form:
<FORM METHOD="POST" ACTION="mailto:email@example.com">Using a "
mailto:" URL as an action may not be supported by your browser. Netscape introduced this extension, and others have since followed suit, but many browsers don't support it. However, mailing forms to yourself is a useful tool for testing out your forms.
Now we can put some input fields in the form. The simplest type is a one-line text input field:
<b>Name <em>(your full name)</em> :</b><br> <INPUT SIZE=40 NAME="fullname">This sets up a text box which can display one 40 character line of text. The user will be able to enter and edit a string of more than that size, but only 40 characters will be visible at any time. The
NAMEyou give is arbitrary, but you can think of it as a variable name for the input field (this analogy will be useful later).
An initial, default string of text can be included with the
attribute on the tag:
<INPUT SIZE=40 NAME="fullname" VALUE="Joe Blow">Multiple lines of text input are also easily handled:
<b>Address :</b><br> <TEXTAREA NAME="address" ROWS=5 COLS=40></TEXTAREA>This sets up a text box consisting of 5 lines of 40 characters. Scroll bars on the box allow you to view additional text, if it doesn't fit within the specified window size. You can also have initial, default text, by enclosing it between the opening and closing
In addition to text input, we may want to allow the user to select from a set of listed options. There are different ways to accomplish this, such as check boxes, radio buttons, and option menus. Here's an example of radio buttons:
<b>Application for :<br></b> <INPUT NAME="status" TYPE="radio" VALUE="New" CHECKED>New membership <INPUT NAME="status" TYPE="radio" VALUE="Renewal">Renewal <INPUT NAME="status" TYPE="radio" VALUE="Change">Address change<br>Note that all three buttons have the same variable name; this is what makes them work together as a group, where only one can be selected at any given time. The "
status" variable will take on the value associated with whichever button is selected when the form is submitted. You can use the
CHECKEDattribute to indicate the default selection.
Check boxes are similar, but have a
TYPE="checkbox" attribute. The
VALUE attribute is assigned to the field if the check box is checked.
Of course, each check box should have a unique
For longer lists of options, check boxes and radio buttons may not be
appropriate. Option menus can be set up, either as pull-down menus or
as scrollable lists, using the
SELECT tag. I won't go into detail here,
since it's beyond the scope of this article.
Finally, we need a couple special buttons on our form, to make it useful:
<INPUT TYPE="submit" VALUE=" Submit Form "> <INPUT TYPE="reset" VALUE=" Clear Form ">The submit button is used to submit the form, i.e. to send it to the URL specified in the form's
ACTIONattribute. The reset button, which is not really necessary but is a nice touch, will clear all of the form's fields to their initial default state.
So, now we can put it all together, into a complete HTML document:
<HTML> <HEAD> <TITLE> Membership Form </TITLE> </HEAD> <BODY> <H1> Membership Form </H1> Please enter all of the relevant information, then use the Submit button at the bottom of the page. <FORM METHOD="POST" ACTION="mailto:firstname.lastname@example.org"> <b>Application for :<br></b> <INPUT NAME="status" TYPE="radio" VALUE="New" CHECKED>New membership <INPUT NAME="status" TYPE="radio" VALUE="Renewal">Renewal <INPUT NAME="status" TYPE="radio" VALUE="Change">Address change<br> <p><b>Membership Number <em>(if you're already a member)</em> :</b><br> <INPUT SIZE=40 NAME="membnum"> <p><b>Name <em>(your full name)</em> :</b><br> <INPUT SIZE=40 NAME="fullname"> <p><b>Address :</b><br> <TEXTAREA NAME="address" ROWS=5 COLS=40></TEXTAREA> <p><b>Phone <em>(daytime)</em> :</b><br> <INPUT SIZE=20 NAME="phone"> <p><b>E-mail <em>(if applicable)</em> :</b><br> <INPUT SIZE=40 NAME="email"> <p> <INPUT TYPE="SUBMIT" VALUE=" Submit Form "> <INPUT TYPE="RESET" VALUE=" Clear Form "> </FORM> </BODY> </HTML>
POSTmethod, and mailed the results to ourselves, we would receive a message something like the following:
From: "Gilbert E. Detillieux" <email@example.com> To: firstname.lastname@example.org Subject: Form posted from Mozilla Date: Mon, 25 Mar 1996 10:39:15 -0600 X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4m) X-Url: http://www.cs.umanitoba.ca/~gedetil/form/form.html Mime-Version: 1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 161 status=New&membnum=&fullname=Gilbert+Detillieux&address=123+Mulberry+Lane%0D%0AWinnipeg%2C+MB%0D%0AR3R+3R3email@example.comThe message body above is actually sent as one continuous line. The MIME-format headers tell us what to expect in the message body. The content type "
application/x-www-form-urlencoded" is used for normal form data, submitted using the
POSTmethod. The content length indicates the exact length of the string to be read. This information is the same when the form is submitted to an HTTP server, and is available to to the CGI program.
The URL encoding of the form data is fairly easy to decode, at least for
a program (it's tedious for humans to do). Each field is listed in
sequence, with an "
=" separating the field name from its value. These
name=value pairs are separated from one another by "
&" characters. Any
spaces in the data are converted to "
+" and any other special characters
are encoded in hexadecimal and displayed as a 3-character string (such
%2C" for a "
Now that we know how the encoding works, we can extract the information from the form, and process it in a program. But, we'll leave that for next time.
This article is copyrighted by MUUG and the specific author(s). You are granted permission to duplicate it for non-commercial purposes only, provided it is not modified and includes this copyright notice as well as all author credits and attributions.
If you found this useful, you might also be interested in other MUUG tutorial articles. Or, why not find out more about MUUG? If you live in or near the Winnipeg area, why not check out one of our monthly meetings?