|UDM Properties
|Parent-Child Relationship |Editing UDMs
 
2
The UDM is a collection of data items presented in tree-form and recorded in XML. This collection is organized in a hierarchical form to reflect conceptual understanding of the way the data elements relate to one another. The purpose of creating a UDM is to capture the data elements to be shown on a given page. The UDM is purely declarative, i.e., it does not embody any algorithmic process. It lists the data elements that should be displayed, the data port they are to be obtained from, the predicates that need to be used upon retrieval and the constraints, if any, to be used when they are stored back into that data store.
In a simple way, each UDM is a tree whose structure represents relationships between the data elements in the designer view.
Each session includes a cache of the UDM trees being edited. The cache can contain a maximum of 100 trees. This enables in speeding up the loading of the UDMs . Instead of re-reading and re-parsing the tree XML each time, the tree can be retrieved directly from the cache. When you ask for a tree, the cache will refresh the tree if it finds that the tree has been modified since it was last retrieved.
  
Each UDM has the following properties:
Every node in the tree has a type attribute whose value is the Java type of the object that will be used to populate the children of the tree.
          Note: This type can be qualified with brackets, e.g., Person[], to mean that the value is actually a sequence of elements
Every non-leaf node in the tree must have a dataSource attribute that determines the means by which that node's subtree will be populated with data elements. (The only exceptions to this are the root and  any nodes designated as synchronizing nodes.) The dataSource attribute specifies a Java class, and an instance of this class will be created when the UDM itself is created.
The name of a node must be an attribute of its parent's type, or the node must be a non-leaf node. In the former case, the node's data value is obtained from the parent's attribute. In the latter case, the node's predicate attribute will be used to retrieve database content to populate its subtree.
    
Each node of the tree is tagged with attributes that describe the node. There are several attribute kinds and the set of required attributes depends on the kind of node in question.
Data types

Nodes may have an associated data type as an attribute. Only leaf nodes correspond to primitive data values (i.e., integer, string and the like). Each non-leaf node serves as means of aggregating its children. Non-leaf nodes may also have associated data types. If a non-leaf node has such an associated data type, it must be a Java class, and it must have one leaf child for each primitive data attribute of the class, i.e., for each method of the class that returns a primitive data type. For example, a node corresponding to a table will have the table's column names as children (attributes). Each such child is referred to as an attribute child. Consider a non-leaf node named employee that has an associated Java type (i.e., Java class name) Person. Suppose further that the Person class has (only) the three attributes id, name and gender. Then the employee node is required to have at least three non-leaf children, and their names must be id, name and gender. These children are the attribute children of the node. We might represent this relationship in a tree form, with child nodes indented with respect to the parent node, as below:
 
                                            employee (of type Person)
                                                      id
                                                      name
                                                      gender

 

Vector nodes
A node of the UDM tree may be designated as a vector node. This means that there can be one or more occurrences (i.e., data values) corresponding to that node. This is in contrast to a non-vector node, which can only have one associated data value. For instance, if the node employee (in the above example) is marked as a vector node, it means that there may be one or more occurrences of Person instances associated with employee. Each such instance has its own copy of the id, name and gender data elements.
Note that a vector node may have other vector nodes as children or descendants. This means that, in each occurrence of the parent aggregate, there can be one or more occurrences of the entire aggregate represented by the child. Extending the above example, we can create a UDM that includes a node named departmentList representing all the departments in a company. Each department has a manager and a vector of the employees in that department as children. We can then mark the department node a vector to represent all the departments in a company.
This yields the following tree:
                                                  company
                                                         CEO (of type Person)
                                                         departmentList (vector of type Department)
                                                                  manager (of type Person)
                                                                         id
                                                                         name
                                                                         gender
                                                                  employeeList (vector of type Person)
                                                                         id
                                                                         name
                                                                         gender

Note, therefore, that a vector can contain other vectors.

There is one caveat associated with vector nodes: a leaf cannot be a vector node. Typically, we will need to identify each occurrence of a vector node's data using, say, an integer identifier, so this is not an unreasonable stipulation.
 
 
2