Cardinality of a Context Node
When a node is created in the context of a Web Dynpro component, the cardinality of the node is specified. The cardinality defines how often a node is to be instantiated at runtime – that is, how many elements of this node are available at runtime.
Cardinality
Cardinality | Description |
1…1 | Only one element is instantiated. |
0…1 | At runtime, no more than one element is instantiated, but it is also possible that no element is instantiated. |
1…n | n elements can be instantiated, but at least one element must be instantiated. |
0…n | Any number of elements of the context node can be instantiated. |
Example
The context node Vehicle is used to describe the fleet of a car rental company. It has the cardinality 1…n and is filled from a database table. A number of attributes of this node have a specific value for each vehicle.
The database table indicates that the company owns three vehicles, each with a unique registration date and unique license plate number. Thus, to display this table in the Web Dynpro application, 3 elements of the Vehicle context node must be instantiated; the cardinality of the node must therefore be 0…n or 1…n. (If the Vehicle node is to be filled with values in the context of another function – for example, from a table of all currently available cars – the cardinality 0…n should be used since this table could be empty – that is, if all cars are rented out.)
At runtime, the Vehicle context node should contain three elements and appear as follows:
As well as these attributes, a context node can also contain additional child nodes:
For each customer of a car rental company, the two attributes “rented from” and “rented till” are listed in the context. At runtime, the context then contains the additional relevant values:
At runtime, each element of the Vehicle node contains a subnode called Customer. These subnodes can contain further elements. Thus, the Customer node of the first element of the Vehicle node (the node with the descriptive data for the red car) contains three elements in its turn, one element for each of the three stored rental procedures.
Lead Selection
The lead selection is extremely important within the nested context structure. The lead selection defines which element of the context is ultimately accessed at runtime. This behavior is easiest to explain using an example:
The UI of the example application contains a TextView element that should display the name of the customer at runtime. Without a clear regulation of the selection path for the context structure, all values of the Name attribute would be equal and it would not be possible to correctly display the name in the TextView element. For this reason, one element of the set of possible elements for the Customer node must be clearly designated. This is achieved by initializing lead selection. The automatic initialization of the lead selection always designates the first element of a node. For the above example, this means:
The lead selection is always automatically on the first element of the Vehicle node (on the node with the data for the red car). Analog to this, the lead selection is on the first element of the Customer subnode (on the element that contains the data for David Grecco).
This special way of designating elements can be depicted as follows in the runtime context.
Only if the lead selection falls on another element of the Vehicle node (as a result of user action or a program step in a method) is the corresponding element of this Customer subnode displayed in the UI element. If the lead selection is set on the second element of the Vehicle node, the customer Pierre Dubois is displayed. The lead selection of the Customer node can be varied at runtime in this way. This enables the names of all available customers to be displayed one after the other in the UI.
Automatic/Manual Initialization
Lead selection is initialized automatically for each newly created context node.
● Using the preset automatic initialization of lead selection:
In this case, the first element of a node is always assigned the lead selection property.
● Manual initialization of lead selection:
If automatic initialization was deactivated, the lead selection can be programmed manually. In this case it is possible to assign this property to an element other than the first element of a node (for example, using an index).
Singleton Property
The singleton property of the Customer context node defines that the elements of this node are instantiated only for one of the three vehicles at runtime – that is, the element that bears the lead selection. If the lead selection was initialized automatically, this is the first element of the Vehicle node. In this case, this is element 1, which contains the data on the red car.
If each customer has multiple addresses, it may be necessary to include a child node for the addresses below the Customer child node. In this manner, the data content of a root node can rapidly become very large if, at runtime, all customers are displayed with all their addresses for each vehicle of the car rental company. To limit the content of a context node at runtime, the context node can be assigned the Singleton property. As a result, the elements of the relevant node are instantiated for only one element of the parent node. This means:
Unlike the cardinality of a node, which describes the number of possible elements within the node, the Singleton property determines whether or not these elements are set for all elements of the parent node (non-singleton) or for exactly one element of the parent node (singleton).
If the Customer node in our example is set as a singleton, the context will be as follows at runtime:
The elements of the Customer child node are only available to one element of the Vehicle parent node and not to all other elements. However, if you want to instantiate the elements of the Customer node for all vehicles, you must set the singleton property for the Customer node to 'false'.
Since the root node of a context is only ever instantiated once, every node directly below the root node (in our example, Vehicle) is always automatically a singleton node.
No comments:
Post a Comment