HTML Forms

HTML Forms are essentially the client side of CGI. They present a nice interface for the user to enter text and select options, embedded right in an HTML page. At the top of this page, you should see the Everything Search. The text area is an <input type=text>. The checkable options with it are both <input type=checkbox>. The "Search" button is actually an image: <input type=image> If you are a user, you will see a <textarea> type field below this node. If you have votes, you can see <input type=radio> at the top of my node, which let you pick between different options. Each tag also takes other parameters, such as name=, so that they are differentiated.

There are five other types that may or may not be on your page:

• <input type=password>
  Like the text type of input, except characters are shown as * so people can't see what you're typing.
• <input type=submit>
  This is just a normal submit button. The image type does the same thing. If you have the Other Users nodelet enabled, you can see the "go" button, which is of this type. The "vote!" button is the same.
• <input type=reset>
  This is stylized the same way as a submit button, except it clears all the fields in the form instead. It can be rather aggrivating to click this and lose all the information you just entered.
• <select>
  If you have the Other Users nodelet enabled, you can see a drop-down list at its top. That's what select is. It lets you pick a value from a predefined list. It can be specified to allow multiple selections, which may be implemented as a list of checkboxes.

There is an excellent tutorial on making HTML forms at the following URL:
http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html

GET vs. POST methods in HTML forms

The purpose of an HTML form is to submit data in order to do something with it, but depending on what that is, one needs to choose between two methods for submitting - GET and POST. This is done by placing METHOD="whichever" inside the <FORM> tag. If you don't specify a method, it defaults to GET.

As a rule of thumb, one ought to use GET if the form submission will have no lasting effect on the state of the world (in other words if it is idempotent) – for example, if the form leads to a SQL select query, but nothing that will change the data. On the other hand, it is appropriate to use POST if the form is about to let the user make a purchase, or send an email. The reasons for this are as follows:

The GET method sends the data using a query string in the browser address bar (like blah.html?fieldname=value), and as such is it treated simply as another address by the browser. This means it is possible for users to bookmark the page with the form submission results, and means they can hit reload and get the same result again with no further dialogue with the browser. This can be convenient, but there are problems. Of course if the form was to make a purchase on an e-commerce site, the user could inadvertantly make a duplicate order. Also, there is a limit on the number of characters that can be placed in a URL (2,083 in IE), making it sometimes more suitable simply for specifying a record ID to view or similar than for submitting one’s name and address, or a write-up on E2, which may be lengthy. In addition, query strings will not accept all non-ASCII characters, and they allow the user to see what’s going on, which isn’t always desirable - so POST is sometimes used even if the query is not idempotent.

The POST method sends the data through the header instead of the URL, meaning we don't see what's happening. As it is the same address in the address bar whatever form data has been submitted, the result that the form data brought about cannot be bookmarked, which is desirable a lot of the time. If you hit reload after a POST form submission, nearly all browsers display a warning dialogue, asking if you are sure you want to resend the data.