|
|
 |
|
|
|
User Data Model
|
|
Note,
however, that the UDM makes no assumptions about the way
in which it is used. For that matter, you could create
another HTML template that accesses the same UDM but
produces an entirely different layout: |
|
|
|
|
<html>
<body>
<table>
<tr>
<td>Last name:</td>
<td>${personUdm.person.lastName}</td></tr>
<tr>
<td>First name:</td>
<td>${personUdm.person.firstName}</td>
</tr>
<tr>
<td>Date of birth:</td>
<td>${personUdm.person.dateOfBirth}</td>
</tr>
</table>
</body>
</html>
|
|
|
The
latter template provides a completely different look
for the same data. This underscores a key point: The
UDM only specifies what data is to be displayed, and
says absolutely nothing about how that data should be
laid out. By contrast, the template specifies only the
layout, and says nothing about the data retrieval or
storage mechanisms. Thus the UDM and the template play
the roles of the middle and client sides of a typical
3-tier architecture.
|
|
|
|
|
|
Data ports
|
|
|
|
|
|
Each
element (or node) of a UDM can have an associated data
port, which determines the
 |
source
of data for
that node. While zeroCode offers a wide range of
data ports, but the most commonly used is the
database data port, so we will focus on that one
for the moment. As a running example, we |
 |
will
use a simple library database that maintains data for
the library’s books and its patrons.
When you create a UDM
node (such as person in Figure 1), you can choose
any name you want for it. When you associate it with
the database data port, you must specify the table
from which its data is obtained. When you do so,
zeroCode automatically adds children to that node
corresponding to each column of the chosen table. To
illustrate, if your database table is named Patron
and has the structure shown at left, then the UDM
(as shown in the zeroCode Design Environment) would
look like the diagram at right.
|
|
|
|
|
|
|
|
|
|
|
|
