Forms in HTML

In HTML version 2, the idea of "forms" (and various related data structures) were introduced. These provided the basis technology for the recent explosion in "electronic storefronts" on the Web as well as several other innovations.

A form in HTML is an area of a Web page which is used to gather input from a human user. The information which is gathered can then be returned to the page's owner using a SUBMIT action.

The form is, as expected, delimited by a <FORM> and </FORM> markup pair.

The <FORM> markup has two important attributes:

ACTION: specifies the action URL of this form. Typically this is the URL of an executable program, see the later discussion of CGI.
METHOD: specifies the way in which the ACTION URL is accessed. There are two methods, GET and POST.

Example:

<FORM
ACTION="http://ironbark.bendigo.latrobe.edu.au/cgi-bin/myprog
    METHOD="GET">

Form Elements

Data is collected in a form by the use of INPUT tags. Each INPUT tag has an associated TYPE attribute.

For example:

<INPUT TYPE="TEXT"

This INPUT type can take several further attributes, eg:

<INPUT TYPE="TEXT"  NAME="Name" MAXLENGTH="64" SIZE="20">

In a browser, this would be presented as a (scrollable) textbox, 20 characters wide (but able to accept 64 characters of input), labelled with the string "Name".

There are several other INPUT types:

TYPE="PASSWORD"
TYPE="CHECKBOX"
TYPE="RADIO"
TYPE="IMAGE"
TYPE="HIDDEN"
TYPE="SUBMIT"
TYPE="RESET"

Form Elements #2

There are two other markup tags used in forms:

SELECT: allows the user to select from an enumerated list of values. Each value is given by an OPTION markup tag, which can take a couple of extra attributes.
TEXTAREA: presents a multi-line text field into which the user can type information. It is specified as a number of ROWS and COLS and can have a NAME attribute and an initial value.

When form information is returned to the HTTP server, it is encoded into a format called:

    application/x-www-form-urlencoded

In this format, space characters are replaced by "+", and non-printing characters are given in hexadecimal format, thus: %HH, where the H characters are the hexadecimal digits of the byte. The fields of a form are encoded as name=value, with each pair separated by the "&" character. Fields with null values are (normally) not sent, nor are unselected CHECKBOXes and RADIO buttons.

Submission Methods

The two ways in which form data can be returned to the server are METHOD=GET and METHOD=POST.

GET: This method is preferred if the submission of the form is not going to have a lasting effect on the global state of the universe - that is, it does not have side effects. For example, it may query a database, returning the result as HTML. A HTTP GET request is issued to the ACTION URL specified in the <FORM> markup tag, with the urlencoded form information appended after a separating "?" character. This can generate very long URLs.
POST: This method should be used where processing of the form is intended to have side effects, eg, updating the contents of a database. In this case, a HTTP POST transaction is performed. The body of the transaction contains the urlencoded form data, as a single long line of text. The POST transaction is directed at the URL specified in the ACTION attribute of the <FORM> tag.

In "real life", GET and POST methods are used pretty much interchangeably, depending on the programmer's preference.

Common Gateway Interface (CGI)

CGI defines the way in which form data is presented to an application program by the HTTP server.

By convention, CGI programs reside in a directory called cgi-bin. When a user clicks the SUBMIT button on a form, the HTTP server starts up the specified CGI program, and makes the form data available to it.

The subtle difference between GET and POST is the way in which a CGI program receives the form data. If the method was GET, the information is usually obtained by examining the contents of environment variables containing the form values as well as some extra useful stuff.

If the method was POST, the CGI program usually receives the form data on its standard input stream, with the extra stuff obtained, as before, from environment variables.

CGI programs can, as a rule, be written in any language (compiled or interpreted) supported on the system running the HTTP server.

On Unix servers, they are commonly written in Perl, C or as Bourne shell (/bin/sh) scripts.

Intranets

The term Intranet is the industry buzzword for the late 1990's.

At its core, the Intranet simply means that an organisation implements a TCP/IP based networking infrastructure behind the firewall (ie, inside the company), instead of using a proprietory system such as Novell Netware, the Microsoft "workgroups" architecture, etc. (although, these companies are moving to TCP/IP as their base technology with rather indecent haste...)

Using TCP/IP on the "corporate backbone" permits a company to move to SMTP & MIME-based email, and to move to a HTTP server and browser oriented mode of information sharing.

One of the big wins is that a browser such as Netscape can become the primary information resource for employees. For example, if I need to discover the status of a project in another department, I can check their Web server, where progress reports are published.

If I need to schedule a meeting with someone, I can check their personal page to view their timetable for the week.

These are examples of "groupware", or "collaboration" applications. At present this market is dominated by proprietory systems such as Lotus Notes.

Client/Server Computing

In recent years, the term client/server has been a serious buzzword.

In essence, it is a way of integrating the so-called "legacy" systems - the "big iron" mainframe applications that still form the core of most large businesses - with desktop computers. Some of the reasons for this are:

The rapid evolution of desktop systems:
- "User friendly" interfaces
- Cheap, and increasingly very powerful.
- It quickly became obvious that, whilst users of such systems could throw togther quite sophisicated software applications, such solutions would not scale to the enterprise level.
The increasingly outdated mainframe-centric data centre and terminal-based EDP departments were faced with justifying their very (expensive) existence. The solution, it seems, is to re-invent the data centre as the server in a new client/server world.
The trend to downsizing, outsourcing and all the other economic rationalist evils of modern management...

Intranets and Client/Server

One of the most profitable sections of the client/server boom has been the rise of "middleware" software company.

Middleware is a generic term for software which bridges the gap between the corporate database and the desktop. It provides tools for networked communications, for structuring database queries and updates and for building the desktop user interface.

This has lead some pundits to propose the humble (?) Web browser (eg, Netscape, Internet Explorer, Cyberdog, etc) as a universal client in a new client/server paradigm. The browser provides all of the user interface functions for all of an organisation's computing requirements. The corporate database is accessed by programs written to the Common Gateway Interface (CGI) specification.

What we may be about to see is a new world where the Web paradigm becomes the basis of everything (;-)

As they say, watch this space.

This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #19.
[Previous Lecture] [Lecture Index] [Next Lecture]

Phil Scott