|Parent-Child Relationship |Editing UDMs
 
5
Special case: 
The Root
The root of the hierarchy is a special case. For convenience, we require that the root serves only one purpose-that of specifying parameters to the UDM as a whole. For e.g., in a UDM such as the one above, that lists the details of a particular company, you may perhaps want the company id as a parameter. So you need to specify companyId as the parameter in the parameter names list of the root.
This also means that the root is exempt from most of the other constraints. It does not have an object store or a data type, nor can it ever be a vector node. It does not make sense to designate the root as read-only.
 
Validation
Each UDM has an associated HTML. zeroCode supports default validation functionality for each UDM. The javascript file which contains the validation is called in the HTML file associated with the UDM. The frame of reference for the validation is the display type. A javascript support file descriptor.js has been added to speed up page loads when there are a lot of visual elements. This scheme is descriptor driven in that each visual element has a descriptor in the generated page, and the initialization and validation code simply loops through the descriptors. This significantly reduces the amount of javascript produced.
Editing Auto UDMs
There may be a number of cases where you need to modify Auto UDMs to meet the needs of a specific page. These modification may be the application of filters on the retrieval of data or the hiding of specific nodes from the generated page. However, new nodes cannot be added  to auto-generated UDMs. A more appropriate mechanism would be to copy an auto-generated UDM to the custom directory, using the zDE File Manager, and then regenerating the HTML after adding a new node. That way, the auto-generated structure is retained, while new nodes can be added.
 
Typical changes to Auto UDMs
The Application of filters
Passing specific parameters from calling pages
Use of session variables
Modification to the order or content of columns shown in List pages
Change in layout of Add, Edit and View pages
Modifications to layout/elements shown in Browse-by pages
Removal of non-mandatory fields on some screens by introducing initialization (in JavaScript) via passed parameters, session variables or hard-coded values
Custom UDMs can be used...
When data in a specific page needs special parameters to be passed from the calling page or needs to use additional session variables
When data needs to be retrieved from/added into/modified in more than one table
When data needs to be retrieved from/added into/modified in Java objects outside the ones that are automatically generated by zeroCode
When a master-detail relationship needs to be implemented for data entry and data display
In Relator pages where data from a related table needs to be shown for the user to select from and insert into a linking table
When data from one or more UDMs needs to be displayed in multiple frames.
Editing Response UDMs:
When the root of  a UDM x is clicked, it shows the response UDM that is served when x is submitted. You can edit the identity of the response UDM as well as its parameter bindings into x. The parameters to the response UDM can be bound to leaf nodes in x, so that when x is submitted, string forms of the appropriate node values are substituted as parameters to the response UDM. Only a leaf that does not have a vector ancestor may be used for binding. consequently, those are the only leaves that you can see in the binding UI.
 
 
5