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.
· 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 The number of instantiated elements of the context node can vary.
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 unique registration dates and unique license plate numbers. Thus, to display this table in the Web Dynpro application, 3 elements of the context node Vehicle 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 very easily be empty – that is, if all cars are rented out.)
At runtime, the context is as follows:
The “Singleton” Property
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:
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 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. In other words:
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 child node Customer are only available to one element of the parent node Vehicle and not to all other elements. However, if you want to instantiate the elements of the Customer node for all vehicles, you must remove the singleton property for the Customer node.
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.
At runtime, every child node set as a singleton contains the elements for exactly one element of the parent node. For this purpose, one element from the set of possible elements of the parent node must be highlighted. This is achieved by initializing lead selection. For each newly created context node, lead selection is initialized automatically, but this setting can also be deactivated. However, lead selection must generally be initialized for every 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 the automatic initialization was deactivated, the lead selection must be programmed manually. However, in this case it is possible to assign this property to an element other than the first element of a node.
For the above example, this means:
The singleton property of the context node Customer specifies that the elements of this node are only instantiated for one of the three vehicles at runtime – that is, the element that bears the lead selection. Since the lead selection was initialized automatically, this is the first element of the Vehicle node, which in this case is the element Red Car. However, it would also have been possible to manually set lead selection for one of the other two elements (for example, using an index).