UDM Issues
 
UDM Traversal Details
   
  The “real” UDM is a construct in the memory of the server. It is represented in the programming world by the UDM file that the designer edits. Hence, the UDM that the designer sees is an accessible representation of the way things will work at run-time, based on the conditions described below. This “accessible” version is recorded in XML format.
UDMs work just like any other web-based program, in that:
Data are retrieved and delivered to the page before it is displayed
Data are stored upon submission of that page
UDMs are of two kinds: search/retrieval only, and Edit/Update. Retrieval UDMs don't have any submission (form) elements. Update UDMs can be thought of as having a retrieval component and an update component, as explained above. The update component is invoked via the UDM's action.
Pages for Edit/Update UDMs can be submitted with two kinds of actions: editAction and deleteAction. The former causes insertion and/or modification of the submitted records while the latter causes deletion. When an Edit/Update UDM is submitted with editAction, the system distinguishes between inserting data and updating data by checking whether the primary key was submitted; if so, it assumes the action required is to update the submitted row, else an insert.
Read and Update nodes are retrieved before display; Insert and Update nodes are stored upon submission.
When a UDM’s page is requested at run-time, the UDM’s data is constructed from top left-hand to bottom right-hand in the tree. This means that, at any given level in the tree, the first Read/Update node is filled first. It’s Read/Update children and then their Read/Update children are filled further, to the lowest level, before the next node at the same level is filled. This is called “pre-order” or “symmetric order” processing, in computing terms.
Upon submission of a UDM’s page, the UDM’s data is updated or inserted in a similar manner to the retrieval. That is, at any given level in the tree, the first Insert/Update node is updated first. It’s Insert/Update children and then their Insert/Update children are updated further, to the lowest level, before the next node at the same level is updated. The one caveat in this case is that update happens in two passes to deal with primary key dependencies. For example, the designer might have created a UDM in which there is a parent 'Employee' node with a child 'Address' node (indicating the employee's address), because that is the natural order of presentation. However, we must insert in the opposite order, because the Employee table has a foreign key to the address table. Consequently, insertion is carried out in two passes over the tree to ensure that no constraint violations occur.
You cannot bind a leaf or node from an Insert node to a Read leaf or node. That’s because the to-be-inserted value is not available upon retrieval – that value only becomes available upon storage.
A given node cannot be bound to the data of the children of vector siblings that are higher than itself in the UDM tree. If the node has a vector ancestor, though, it can certainly be bound to children of that ancestor.In specific terms, a node x can have its retrieval binding set to a node y only if:
a)  x and y are both leaves
b)  x is not an ancestor of y
c)  If a node z is the lowest common ancestor of x and y, then there is no vector node along the path from z to y (although z itself is allowed to be one)
d)  y occurs "earlier" in the tree than x does, i.e., y would be visited earlier than x in the UDM traversal.
For storage bindings, a node x can have its storage binding set to a node y only if all of (a) through (c) above hold, although (d) is not necessary.
Data from non-vector siblings and their children are available freely to a node, subject to the conditions 4 and 5 above.
The parameters passed to a UDM are not available to the Insert nodes of that UDM, since these parameter values are destroyed at the end of the retrieval process. For Update nodes, these parameters can be used for the retrieval of that node, but not for its storage.
Session Variable Usage
Session variables can be inputs to a UDM, outputs from a UDM, both or none. If marked as input, they will be retrieved from the session manager and used during the retrieval process (if they are included in the UDM’s retrieval nodes anywhere). This implies that a session variable used in a UDM must have been defined in the session before it is requested by a UDM. If it is not, the system attempts to redirect the user to the “referring” page, i.e. the page that caused this UDM to be retrieved was submitted. If that page was not submitted but was invoked through a link, instead, redirection occurs to the page that is nominated as the “defining URI” for that session variable.
When a session variable is marked as output from a UDM, this means that that UDM sets the value of that session variable. It also means that that session variable need not exist before the UDM is invoked. If it does exist, that value is overwritten with the output of the UDM. When marked as output from a UDM, a given session variable must be bound to the leaf of an Update or Insert node in the UDM, for the obvious reason that the session variable will be given the value of that leaf.
The defining URI of a session variable must have that session variable marked as Input only to that UDM. 
When a session variable is marked for input and output, it means that the value of that session variable will be modified by the UDM. The session variable must then be bound to a leaf of an Insert or Update node in the UDM.