next up previous
Next: Included instances
Up: The WOM language
Previous: Action links; deleting sessions

Paths

 

We saw that every instance has an id attribute: if the author does not initialise this, the compiler will generate a value for it. We have also seen that many instances can contain other instances, as almost all our sample pages have done. WOM gives every instance a ``name table'' mapping the ids of its contained instances to the instances themselves. Thus the page

<TextField t1 size=10 value="0">
<TextField t2 size=11 value="1">
has a name table which maps "t1" to the first instance, and "t2" to the second.

There may be several levels of containing instance: an application root could contain a page which contains fields, for example. This gives rise to a name hierarchy similar to a directory hierarchy. As with directories, we refer to these hierarchically-structured names as paths.

One place they are needed is in code inserts, so that the author can refer conveniently to instances and their attributes. In the factorials code insert, the line n = $input~getValue refers to the built-in value attribute. This, as already mentioned, holds the data last submitted from a field. $input identifies the field itself, and the compiler will translate this into an Object Rexx expression that returns the appropriate instance. The $ character is not permitted in Object Rexx, so there is no risk of ambiguity.

Paths are written as a sequence of ids separated by dots. There are four special names that can be used in them. ROOT is one of these, and denotes the top instance in the hierarchy, like the top-level slash in a directory path. The other names are SELF, PARENT and SENDER, the last denoting the instance whose HTML the server has been asked to send back.



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