Singleton and Non-Singleton Nodes 

In general, dependent nodes are represented by a single node instance, whose content – that is, its node collection - changes each time the lead selection of the parent node changes. Such context nodes are known as single nodes. The existence of a single node instance considerably reduces the resources that are required at runtime. This improves the performance of the application significantly. However, the use of singleton nodes also results in programming restrictions. This means that the user can only access data of the child nodes that belong to the code element (lead selection) currently selected in the parent node. Consequently, you cannot read - for example - the address fields of a business partner X if business partner Y is currently selected. Each modification of the parent node lead selection causes a data modification of the singleton child node.

Therefore, Web Dynpro allows you to define additional non-singleton nodes. Each non-singleton node has one node instance for each node element of the parent collection at runtime. The advantage is that each instance can be accessed directly. When using non-singleton nodes, the nodes are only created when the node values are retrieved. This can save resources that otherwise would slow down the performance of the application.

Note that singleton nodes should only be considered singleton in relation to their parent nodes but not in relation to the context. Each instance of a non-singleton parent node has exactly one instance of the singleton node.

The singleton property can be defined for all dependent context nodes. It is either true or false:

·        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 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.

·        singleton = false: A child node instance exists for each node element in the parent node. The content of this node instance does not change. The node instances of the child node can be accessed using generated context interfaces.

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.
Child nodes of type singleton always refer logically to an element of the parent node, that is, the one in the lead selection. If the parent node does not have a lead selection, then the singleton child node is invalid, even though it exists.

Example

The independent context node Customers contains the two independent child nodes Address and Orders. The Web Dynpro runtime environment keeps only one single instance (singleton) of the child node Orders for the parent node Customers. The list of node elements {(CD, 12€), (DVD, 30€)} in the context node Orders always refers to the lead selection that is selected in the parent node, here the node element number 1 (Smith). If the lead selection of the parent node changes, the singleton child node has to be refilled. Singleton nodes are filled with node element instances using what are called supply functions. The content node Address is of type non-singleton, that is, for each node element in the parent node Customers (that is, for each individual customer data record), one node instance of the child node Address exists at runtime. This means that all addresses can be displayed at once, for example in a table. Furthermore, the remaining node elements can be accessed independently of the lead selection of the parent nodes (node element number 1, customer Smith).