|
|
|
Parent-child
relationships |
|
Since the purpose of the UDM tree is to
depict the conceptual relationships between data elements,
we will require certain constraints on the data types of parents
and children. For now, we will formulate the constraints based
on the assumption that all data elements are drawn from the
database object store. The conditions are the following:
|
|
|
If a node is a child of the root, then these constraints do
not apply. |
|
|
If a node is not read-only, and is not
a child of the root, then the table associated with the node
must have a foreign-key dependency with the table associated
with the parent of the node. For example, a node named employee,
of type Person, might have a child named Country Of Origin,
representing the country from which the person originates. The
child's type could be Country, thus requiring a foreign-key
relationship between the Person and Country tables. Furthermore,
all the foreign keys in the node's table must be determined
by other nodes or tree parameters (more about this below).
|
|
|
If a node is read-only, then there must be a valid join path
(consisting of a sequence of one or more tables involved in
a multi-table join) between the parent's table and the node's
table in the database. Moreover, any unused foreign key of a
table along this path must be bound to a tree node or tree parameter
(more about this below). |
 |
|
|
The
Datatree structure has four classes with the following hierarchy:
|
|
DataTree Node
Datatree non leaf Node
Datatree Vector Node
Datatree scalar Node
DataTree Leaf |
|
|
|
|
|
| The UDM
requesthandler has the code to read a file 'variable.xml'
in the requested directory for variable definitions, so
that commonly used site globals can be easily initialized
. This is intended primarily
for serving up semi-dynamic content pages, and works as
follows. Suppose the user requests an HTML page at the
URI /zcSite/mySite/content/showme.html,
and suppose that the HTML file exists but there is no
corresponding UDM file. The handler then looks for a file
named variables.xml in
the same directory as the HTML file (typically, the directory
webFiles/templates/content),
extracts variable definitions from that file, uses them
to substitute any FreeMarker variable references within
the template file showme.html,
and then serves up the result to the requesting user.
This enables us to maintain all site- or subsite-global
definitions (e.g., the webmaster’s e-mail, the web site
address or contact information) in a single file, instead
of having to propagate changes to lots of HTML files.
Note that each subdirectory of the web site can have its
own variables.xml file.
For example, we can create a variables.xml
file that defines three variables whose names are email,
website and contact_info
looks like this: |
|
<?xml version="1.0"?>
<variables>
<variable name="email">anyname@zerocode.com</variable>
<variable name="website">www.zerocode.com</variable>
<variable name="contact_info">
5201 Great America Pkwy #356<br>
Santa Clara, CA 95054
</variable>
</variables>
|
|
|
We
can then refer to or
in the template file
showme.html, instead of hard-coding
these values into the HTML. |
|
Notice, in this file, that variables can have multi-line values
(as does contact_info). Notice
also that variable values can have embedded HTML markup, as
long as the tag symbols are quoted properly. In the above example,
the tag <br> is represented
as <br>. In general,
however, embedding HTML markup in variable files is not a good
idea because it violates separation between data and markup.
|
|
|
| |
Foreign-key
constraints |
|
|
|
Consider
a non-leaf node whose type is associated with a database table,
and suppose that the table includes several foreign keys to
other tables. Naturally, we can insert a new record into that
table only if we have specified a value for each foreign key
column in the new record (unless, of course, the column can
be null - we'll assume that it cannot). This means that if we
are to allow insertion, we must bind each foreign key of the
node to a value obtained from somewhere. The solution adopted
with the UDM is to require that each foreign key be bound to
the value of a node that occurs higher up in the tree. For instance,
consider the following extension of the earlier example: |
|
company
CEO
(of type Person)
departmentList
(vector of type Department)
id
manager (of type Person)
id
name
gender
departmentId
employeeList
(vector of type Person)
id
departmentId
name
gender |
|
|
|
We have added departmentId fields to the Person record, with
the intent of identifying the department with which the person
is associated. In this tree, it is natural to bind the departmentId
field of the employeeList and manager nodes to the id child
of the departmentList node. Such a "binding" means
that, if a new Person record is inserted into the database as
a new employee via this UDM, the departmentId field of the record
obtains its value from the id field of the departmentList node
of the UDM |
|
|
|
|
