Cardinality Property:
The Cardinality property is composed of a pair of values that controls the maximum and minimum number of elements {cn} may contain at runtime.
The Cardinality property may have four possible values:
* 0...1: Zero or one
* 0..n: Zero or More
* 1..1 One and only One
* 1..n: One or More.
The first part of the cardinality describes the minimum number of elements that {cn}'s
Element collection may contain. This value is either Zero or One, and is stored as a Boolean value.
This value can be obtained at runtime by calling the method
node {cn}.getNodeInfo().isMandatory().
The Second part of the cardinality describes the maximum number elements that {cn}'s element collection may contain. This value is either a '1' or an 'n'(meaning any) and is stored as a Boolean value (false = 1,true = n).
This value can be obtained at runtime by calling method node
{cn}.getNodeInfo ().isMultiple().
If {cn} has a cardinality of 1..<something>, then it can be assumed that after the context has been initialized, there will be at least one element present in the node collection. This element is known as default element and cannot be deleted.
If you attempt to perform some action on a node that would violate the constraints of the cardinality, then you will get a runtime exception in the context e.g., trying to add a second element to a node of cardinality 0..1 or trying to delete the last element from a node of cardinality 1..n.
Singleton Property:
The Singleton property critically affects the relationship between the child node {chn}and its parent node {cn}.
If {chn} is decalred at design time, the generated interface for this node will vary depending on whether it is a Singleton or Non-Singleton node.
There is one to one relationship between each element in the parent node's element collection and the corresponding child node.
If {cn}has n elements in its element collection then you will have 'n' distinct instances of the non-singleton child node {chn} .
Non-Singleton child node can be created by their respective parent element.
Singleton child nodes however are associated with their parent node on a per node basis.
Irrespective of the number of elements in the parent node's element collection, there will only ever be one instance of the singleton child node {chn}.
The Singleton child node holds the data relevant for the element at the lead selection in the parent node's element collection.
Singleton child nodes must be created by their parent node. Since there can only ever one instance of singleton child node. It is impossible for an element in a parent node collection to create singleton child node.When singleton = true: Newly defined context nodes are of type singleton by default. This means that a child node instances exists for each parent node, not for each node element in the parent node.
The varying relation between child and parent nodes is important for singleton and non-singleton nodes. Whereas singleton nodes are related to the parent node, non-singleton nodes always refer to a node element of the parent node at runtime
The content of the child node, that is, the list of the node elements it contains, changes each time the lead selection of the parent node changes. Since the context root node always has exactly one element, all the nodes that have the context root node as their immediate parent must, by definition be singleton nodes.
Further to this, the definition of a Singleton child node {chn} immediately implies that it must be repopulated every time the lead selection in its parent node {cn} changes. This job is performed by declaring a Supply Function for the singleton child node.
Supply Function:
Supply functions are used to repopulate child nodes when the lead selection in the parent node changes. The Web Dynpro Framework automatically calls a supply function when the lead selection in the parent node changes.
Selection Cardinality:
All the context nodes maintain a collection of elements, where an element is a single instance of all the node's child entities. During the operation of a Webdynpro controller, it is often becomes necessary to make certain node elements as requiring processing
(e.g., after a user has selected multiple rows in a table). The number of elements that may be selected is controlled by the selection cardinality, which may take one of the same four values as the node cardinality.
In the same way that the node's cardinality controls the maximum and minimum number of elements permissible within the node collection at runtime, so the selection cardinality controls the maximum and minimum number of elements that may be selected at any one time.
Unless you say otherwise, a node will have a selection cardinality of 0..1 meaning that you may select zero or one element at any one time. If such a node were displayed using a table UI element, you would be able to select only one row at a time. However, if you wish to allow the user to select multiple rows, you will need to change the selection cardinality to 0..n, meaning that zero or more elements may be selected.
No comments:
Post a Comment