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.