Forms

Outline

Forms and Inputs

So far in our web pages, we've just been giving the user information. Now, we want to get some from the user. We'll do this by having them fill out a form, just like the ones you did on the first day of cs110 lecture (and whenever you buy something online). Click here for an example form. You can look at the source to see how it's done.

The main tag is the FORM tag. Like TABLE, UL and a few others, the FORM tag is just a container; it doesn't do much by itself. 

 <form name="my_data">
 ... inputs go here ...
 </form>

Note that, for reasons that we'll discuss in a later lecture on form validation, it is useful to name each form. The form above is named my_data, but that's just an example. You can name a form pretty much anything, though you should stick to the same character set as for JavaScript variables (letters, digits, and underscores).

The body of the form can contain one or more inputs, (in addition to any other HTML, JavaScript code, text, and images). Many of these use the INPUT tag, but there are tags called SELECT and TEXTAREA that also provide input.

We will also name all of our inputs. This is useful when the form data is emailed to us, so that we will know what input each value is associated with. For example, suppose we have an online form for course evaluation. Is "strongly recommend" the value associated with the course or the instructor? If that value is associated with an input named "course," the answer is obvious.

The INPUT Tag

The INPUT tags have several different types, which you specify using the TYPE attribute. The types include at least the following:

Examples: 

<form name="my_data">
    <input type="text"      name="age">
    <input type="password"  name="secret">
    <input type="radio"     name="station" value="WZLY">
    <input type="radio"     name="station" value="WBUR">
    <input type="checkbox"  name="cool">
    <input type="hidden"    name="form_author" value="me">
</form>

You can see more examples by looking at the source for the example form. A small warning: if a checkbox isn't checked, no value is reported in the email, so don't be concerned if you don't see one.

Radio Buttons and Checkboxes

Each radio button input is part of a group of mutually exclusive buttons: if you click on one button, it is selected and whatever used to be selected is de-selected. This is more intuitive to try than it is to describe:

favorite fruitfavorite technology company
apple Apple
banana Google
orange Microsoft

The crucial question is, how does the browser know that when you click on the first "apple," it should deselect banana and orange, but not Apple, Google or Microsoft? The browser is not able to get any clues from the layout of your buttons: you might just as easily have arranged the table horizontally instead of vertically. (Look at the source to see how ugly that might be.)

The rule is that the browser deselects all other inputs that have the same name as the input you selected. Thus, the name of a radio button is crucial: it defines the group of mutually exclusive options.

Although checkboxes are not mutually exclusive the way that radio buttons are, they also form groups based on the name of the input. This is reflected in the email that you are sent: checked boxes are grouped together as one set of responses.

The SELECT input

To specify a menu, from which the user can choose only one option, you use the SELECT tag inside the form. You specify the NAME of the input in the SELECT tag, and each menu item is specified using the OPTION tag. Here's an example:

Drink: 

<select name="beverage">
   <option>Coke
   <option>Pepsi
   <option>Beer     
   <option>Wine
</select>

The email message will display whichever option the person chose.

The TEXTAREA input

If you want to allow your user to type in a long response, you should define a text area inside your form. This tag has attributes called ROWS and COLS that let you specify the size of the area. The default value is the region between the beginning and ending tag, so if you want the default value to be empty, put the tags right next to each other, as in the second example here:

Please tell us your deep thoughts:

<textarea name="thoughts" rows="3" cols="40">
A chicken is an egg's way of making another egg
</textarea>

More typically, the TEXTAREA tag is defined to have an empty initial value, in which case you must put the closing tag right after the opening tag, thus: 

<textarea name="thoughts" rows="3" cols="40"></textarea>

Don't let even a single space creep in, or the initial value will be a string of one space, and not the empty string. That will affect your validation code.

More INPUT Tags

Here are some more INPUT tag types. There's no input from them, but they otherwise share the common syntax for the INPUT tag. You should not name these elements, since there is no data associated with them.

Processing Form Data using JavaScript

Another important reason for naming inputs is so that we can refer to them from JavaScript code. The general scheme is that an expression like the following gives the value of a text input. You can essentially treat this kind of expression like you would a variable: it has a value and you can store new values into it.

window.document.formname.inputname.value

Note that the "window.document" part is optional in most browsers that we've experimented with. However, it is standard in various web references, so we consider it to be (at least) a good idea.

Here are some examples of processing form data.

To understand the code of the last one, you have to know that for radio buttons and checkboxes, you can find out whether the input is checked by looking at the value of the following. It is a boolean value: true if the input is selected and false, otherwise.

window.document.formname.inputname.checked

CGI

What happens when the form is submitted is determined by the CGI (Common Gateway Interface) protocol, which sets the rules by which form data is sent to servers and processed by programs, usually called CGI "scripts." A CGI script can do anything it wants: it can send email, interact with a database, create a document, contact other users, or whatever. The electronic commerce web sites that you know, like amazon.com, all work via CGI scripts.

A form can specify what script is to process the form data (via the ACTION attribute), and how it should get the data (via the METHOD attribute). The example that we will use in this class is a CGI script that emails the data to some recipient. When you want the data to be emailed to someone with the help of Puma (acting as a mail server ) you can write: 

<form name = "my_data"
   method="post"
   action="http://cs.wellesley.edu/cgi-bin/eform.cgi">

The value of the ACTION attribute is a CGI script that will package up all the form information and email it someplace. There are two methods, GET and POST. The GET method collects all the form inputs in the URL. (You've probably seen this sort of link from sites like Google Maps .) On the other hand, the POST method collects all the form inputs into something called "standard input." We will always use the POST method in this class.

Echoing the Data

The first CGI script we'll consider is not particularly useful by itself, but is very helpful for debugging forms. It just echoes the data back to the browser, in a nicely formatted way. It also tells you a few other things it knows, such as the IP address you're browsing from and the time you submitted the form. The script is called dump.cgi and it lives in http://cs.wellesley.edu/cgi-bin/dump.cgi .

Exercise 1

Emailing the form data from Puma

Since CGI scripts can do such different things, each one can have its own behavior and rules. The one we will use in this course is called eform.cgi and it is designed to email the information on the form to someone. It can do this in one of two ways:

You already know how do to the first case. There are two steps:

  1. Make the FORM tag look like this: 
    <form method="post"
      action="http://cs.wellesley.edu/cgi-bin/eform.cgi">
  2. make sure there is recipient for the email message. This is usually done via a hidden input: 
    <input type="hidden" 
       name="_recipient" 
       value="me@wellesley.edu">

    (The name begins with an underscore because it's required; the script will complain if that input is missing.) That's all. The downside of this simple approach is that the resulting email message isn't pretty. It is unformatted, a long string of form contents.

To have a formatted email message is an optional advanced technique for the interested reader. Follow the link to find out how.

No Referrer

To avoid abuse by spammers, eform.cgi requires that the form be on the server. If your form is not on the server, you will get an error message saying

No referrer.

This error commonly occurs when you are testing your form on your local desktop machine, so that the URL for the form is file:///.... Sorry, but that won't work.

Exercise 2

Solutions to Exercises

Summary

In this lecture, we learned

Optional reading: Meyers Ch. 14-15, Thau Chapter 7.

© Computer Science 110 Staff
This work is licensed under a Creative Commons License
Date Modified: Monday, 31-Mar-2008 16:07:03 EDT