Having described the motivation for Web-O-Matic, we proceed to the means. Some experiments with dynamic plots had shown the need to maintain large amounts of local state on the server, and this gave rise to the idea that Web pages be thought of as composed of objects, each living its own life on the server and responding to messages from the client. One important action every object can do is to display itself as HTML. There were already some systems around which worked in this way, such as the Geometry Center's W3Kit [Geometry Center W3Kit]: we discuss in Section 6 why Web-O-Matic is unique.
The pseudo-code below shows how an IntegerField might behave.
This is a data-entry field into which the user can type a string. If the
string is a valid integer, then next time the form containing the field
is displayed, this string will appear. If it is 2C, =1, or
some other string that has no meaning as an integer, then it will still
appear, but the field will also have a big red arrow or some other error
indicator next to it. This indicator will disappear if the user then
types a correct value and resubmits the form.
Similarly, a field from which a program takes data can be regarded as an object which behaves as above, but which also, if the string sent by the client is valid, writes it into a file or memory area from which the program can read it.
Of course, the objects as the client sees them do not persist, but are redrawn every time a page is sent back to the browser. However, there is still a sense in which two fields in the same position of two successive forms can be regarded as the same field. Their common position and context is sufficient to give them a shared identity, and hence to make them the same object [Lucas 1973].