FORMS

Interactivity on the Web

Where do I get the form data from?

There are two methods which can be used to access your forms. These methods are GET and POST. Depending on which method you used, you will receive the encoded results of the form in a different way.

The GET method
If your form has METHOD="GET" in its FORM tag, your CGI program receives the encoded form input in the environment variable QUERY_STRING.
The POST method
If your form has METHOD="POST" in its FORM tag, your CGI program receives the encoded form input on stdin. The server will NOT send you an EOF on the end of the data, instead you should use the environment variable CONTENT_LENGTH to determine how much data you should read from stdin.

But what does it all mean? How do I decode the form data?

When you write a form, each of your input items has a NAME tag. When the user places data in these items in the form, that information is encoded into the form data. The value each of the input items is given by the user is called the value.

Form data is a stream of name=value pairs separated by the & character. Each name=value pair is URL-encoded, i.e. spaces are changed into plusses and some characters are encoded into hexadecimal. Keywords are separated with the + plus.

Because others have been presented with this problem as well, there are already a number of programs which will do this decoding for you. The basic procedure is to split the data by the ampersands. Then, for each name=value pair you get for this, you should URL decode the name, and then the value, and then do what you like with them.

GET

Using the GET method assumes there is a CGI script and the browser is sending a request to "GET" the information or action from the script. For example, the page counter, the system variables, date and time, and the calendar are "GETs". In each case the HTML text has a line that requests something from the server.

For example, the date and time routine is invoked using the statement

    <!--#exec cgi="/cgi-bin/dater.cgi"-->

The routine to be invoked is named "dater.cgi", and resides in the cgi-bin directory of the server. The actual location and name is very server dependent.

When the routine is invoked, the server executes it. Depending on what the routine does determines what happens. In this case, the routine is a UNIX shell script that calls the system time and date routine then sends that information back to the browser in the appropriate format - meaning HTML statements.

To give you an example, here's the script for dater.cgi:

      #!/bin/sh
      echo ""
      date +"%a %b %e, %Y"
      echo ""

All this routine does is invoke the UNIX date routine and returns the information in a specific format. The echo command means to display on the screen EXACTLY what is contained on the rest of the line. In other words, display a blank line. The requirement of this approach is the need to work with UNIX shell commands. Many providers do not allow users to develop CGI routines. Most provide a small group of "canned" CGI routines, such as the collection at BPL.

To invoke the system environment routine vars.cgi, a PERL script is used:

#!/usr/bin/perl

print "Content-type: text/html\n\n";

$ss = $ENV{"SERVER_SOFTWARE"};
$sn = $ENV{"SERVER_NAME"};
$su = $ENV{"SERVER_URL"};
$gi = $ENV{"GATEWAY_INTERFACE"};
$rm = $ENV{"REQUEST_METHOD"};
$sp = $ENV{"SERVER_PORT"};
$rh = $ENV{"REMOTE_HOST"};
$ra = $ENV{"REMOTE_ADDR"};
$ru = $ENV{"REMOTE_USER"};
$ua = $ENV{"HTTP_USER_AGENT"};
$hf = $ENV{"HTTP_FROM"};
$sc = $ENV{"SERVER_PROTOCOL"};
$path = $ENV{"PATH_INFO"};
$qu = $ENV{"QUERY_STRING"};
$sm = $ENV{"SCRIPT_NAME"};
$ht = $ENV{"HTTPS"};
$hk = $ENV{"HTTPS_KEYSIZE"};

print "<br>Server Software: ".$ss."\n";
print "<br>Server Name    : ".$sn."\n";
print "<br>Server URL     : ".$su."\n";
print "<br>Gateway I/F    : ".$gi."\n";
print "<br>Request Method : ".$rm."\n";
print "<br>Server Port    : ".$sp."\n";
print "<br>Remote Host    : ".$rh."\n";
print "<br>Remote Address : ".$ra."\n";
print "<br>Remote User    : ".$ru."\n";
print "<br>User Agent     : ".$ua."\n";
print "<br>Email from     : ".$hf."\n";
print "<br>Server protocol: ".$sc."\n";
print "<br>Path Info      : ".$path."\n";
print "<br>Query String   : ".$qu."\n";
print "<br>Script Name    : ".$sm."\n";
print "<br>Security?      : ".$ht."\n";
print "<br>Keysize        : ".$hk."\n";
1;

Note that the line print "Content-type: text/html\n\n"; is required to tell the web browser that the information returned is plain text. The rest of the statements are PERL commands that get the specific information from the $ENV or system environment table, and formats it (using the print statements) into HTML statements.

Again, the need to know not only the UNIX system but also the PERL language.

POST

The POST command, on the other hand, allows the browser to send information to the server, and let the server do something with it. Anything that can be done with a GET can also be done with a POST. A GET, however does NOT allow the browser to send information or make a request to the server.

The POST is useful for

posting a message to a mailing list, bulletin board or a newsgroup
getting information about existing server resources
providing form data to a CGI program

Using Forms

There are two parts to a form - designing the physical layout and handling the interaction. Most forms require a CGI script (server-side include) but simple mail can also be useful and doesn't need special CGI. For the form to do something, there must be a CGI script that is invoked when the SUBMIT button is selected.

Any HTML editor (HotDog, PageMill, etc) support the basic design of the layout - the fields, actions, defaults and so on.

FORM components - The Basics

See the HTML reference card for details or pp 44-49 in Aronson.

Form Tags & Attributes
- <FORM>
  - Description - input form
  - Attributes - Action, METHOD, ENCTYPE
- <INPUT>
  - Description - Input field
  - Attributes - ALIGN, NAME, type, VALUE, CHECKED, SIZE, MAXLENGTH, SRC
- <SELECT>
  - Description - Selection list
  - Attributes - name, MULTIPLE, SIZW
- <OPTION>
  - Description - selection of an item
  - Attributes - SELECTED, VALUE
- <TEXTAREA>
  - Description - multi-line text input
  - Attributes - name, rows, cols
In the SIGGRAPH example, the FORM tag is
```
   <form method=POST action="mailto:xxxxx@acm.org">
```
I'm sending information to the server using a POST command, and the server program I want invoked is the "mailto". All the information from the form will be packaged into a mail message to me at xxxxx@acm.org. The form begins with the <FORM> command and ends at the </FORM> command.
Text fields
Text fields are usually a single line, and the NAME attribute is assigned a unique name. On the SIGGRAPH example, name, street, city, state, zip, email and fax are the names of the specific text fields.
Text area
If a single field is not large enough to capture the information, such as detailed comments, a TEXTAREA can be used. By defining the number of rows and columns, the free-form area is created on the page.
```
     Any other comments, questions, requests, etc?
     <br><textarea name="comment" rows=8 cols=60></textarea>
```
Radio buttons
There can be any number of radio buttons in a set, but only one of the buttons can be selected at any given time.
```
     Are you currently a member of ACM?
     <input type="radio" name="acm" value="Yes" checked>Yes
     <input type="radio" name="acm" value="No">No
```
In this example, the set of radio buttons is named "acm" and the value of each is set. Another attribute is checked. By setting this attribute, that value is the default unless changed by the user.

Check boxes
As with radio buttons there can be any number of check boxes in a set. Unlike radio buttons, any number of the boxes can be checked at any time.

Are you currently a member of the following? [Please check all that apply]
<br><input type="checkbox" name="other" value="IEEE">IEEE
<br><input type="checkbox" name="other" value="HFA">Human Factors Association
<br><input type="checkbox" name="other" value="NCGA">NCGA
<br><input type="checkbox" name="other" value="CLA">CLA

PopUp Menu and List Selection field
A selection list is a box that contains a set of options for the user to choose. In the SIGGRAPH example, the name is "chapter" and the SIZE command notes that 5 items are to be displayed.
```
What is the closest ACM Chapter or other ACM Local SIG to you?

<select name="chapter" size="5"> 
    <option>Denver
    <option>Boulder
    <option>Ft Collins
    <option>Colorado Springs
    <option>none
    </select>
```
In order to save space on the form and to show only that information needed at any specific time, the PopUp menu works fine. The PopUp Menu is the same, but the SIZE is only 1, hence the need to display the information in a "hot menu".
Submit & Reset Buttons
The last tag in the form allows the user to complete the form and send it or to erase everything. The value of the button will be displayed in the button on the screen. If left off, the defaults are SUBMIT and RESET.
```
     <input type="submit" value="Send">
     <input type="reset"  value="Don't Send">
```

Return to Teknikos Home Page