next up previous
Next: Object-oriented Web programming and System Limit Programming
Up: Introduction and background
Previous: Economic models on the Web: The Institute for Fiscal

The problems of CGI programming

Programming these dynamic pages can become complicated. For example, when a user logs in, we would like every Web page sent back to bear a copy of their username, and a note of the time the session was started. The first helps in keeping pages printed by different users distinct; the second is a check against accidentally creating more than one session and getting them mixed up. Users had to be able to run our economic model and plot the output graphically, and then interact with the graph by, for example, zooming in around a given point to view its neighbourhood in more detail. We use Netscape frames, with navigation buttons on the outer frames and results in the main one: users must be able to expand the main frame so that they can see more of its contents at once, for example because they might have poor-resolution screens.

The lowest-level interface between a Web-page author and the user's data is the ``Common Gateway Interface'' (CGI), in which the data is sent to the server as a sequence of name-value pairs together with a URL. In general, the name identifies a field, menu or other data source, and the value is the data the user entered into it. The author can access these pairs through operating-system environment variables or some equivalent.

A common way to generate dynamic Web pages from such data is to have a server script that calls a separate routine or program to process the data and return its results as strings, and that then prints an HTML template page back to the server, filling slots in it with these strings. There are a number of CGI-scripting libraries to help with this, many written in Perl and some in Rexx. This way of doing things has the defect that the page templates are not coded in HTML, but rather as ``write'' statements that emit the HTML. It also requires a good level of programming ability, and a lot of experience with Web programming, to solve problems such as handling multiple simultaneous users.

There are various pre-processors around to make things easier. These range from simple tools allowing pages to be written as HTML with embedded Tcl commands, to ambitious systems such as NeXT's WebObjects and Universal Access' MetaHTML. None of the simpler tools were adequate for us, being too ad-hoc and requiring more knowledge of the way the command language --- Tcl or whatever --- interacted with the rest of the setup. The more ambitious systems were either not in existence at the time we started, didn't run on our machines, or didn't suit our needs. These included the ability to let the user enter and correct large amounts of numerical data, which most ``shopping cart builders'' (tools to help the Web-page author build on-line shopping services) for example don't need to worry about.


next up previous
Next: Object-oriented Web programming and System Limit Programming
Up: Introduction and background
Previous: Economic models on the Web: The Institute for Fiscal



Jocelyn Ireson-Paine
Fri May 30 14:03:06 BST 1997