Context refers to the single hierarchical data storage structure assigned to every Web Dynpro controller. The data is held in the context for the life span of the controller. This is lost with the termination of the controller instance.
CHANGING THE CONTEXT ( 1 )
You can select the controller and open it in the Change mode in order to modify the context of the controller.
Next, you select the context tab to get the hierarchical structure of the context.
You can display the properties by choosing the context node or attribute, accordingly.
CHANGING THE CONTEXT ( 2 )
You can edit the properties of all the nodes and attributes simultaneously by simply selecting the Switch Context Editor View option.
CREATING NEW CONTEXT ELEMENTS
Nodes and attributes constitute a hierarchical arrangement of entities, from which all controller contexts are constructed.
The parent node of a context is known as the context root node; has fixed properties; and cannot be deleted.
The main abstraction class used for runtime data storage within the Web Dynpro framework is known as context node. The node may have attributes or other nodes as children.
A context attribute is an entity within the context, which cannot have children. You can create a context attribute only as the child of some parent node, whether it is the context root node itself or some other node.
You can open the context menu of the context node to create the respective node and attribute.
CONTEXT NODES AND CONTEXT ATTRIBUTES AT RUNTIME ( 1 )
You create the metadata structure at design time, within which the runtime data is stored.
During runtime, a node object is automatically created for the context root.
In addition to the creation of the node object, an element object is created .An element is a unit that aggregates all the child entities of a node. The reference to the element created is stored in the node’s attribute COLLECTION.
CONTEXT NODES AND CONTEXT ATTRIBUTES AT RUNTIME ( 2 )
At design time, the context attributes A1 and A2 are created, which are related to the context root.
A corresponding structure is created at runtime only if the context attributes are related to the context root. The reference to this structure is stored in the elements attribute STATIC_ATTRIBUTES.
CONTEXT NODES AND CONTEXT ATTRIBUTES AT RUNTIME ( 3 )
The context nodes N1 and N2, as well as the context attributes A1 and A2 are created under the context root at design time.
Now at runtime, a node object is automatically created for each subnode of the context root. The attribute CHILD_NODES of the context root element stores the relevant references.
NODE COLLECTION CARDINALITY
Cardinality is a property of every context node. This property defines the maximum and minimum number of elements that the node collection can hold at runtime. Therefore, cardinality comprises two values. The lower limit cannot be lower than zero (0) and the upper limit cannot be higher than n.
Four possible combinations give rise to cardinality values (specified as <Min>..<Max>):
0..1: Zero or one element permitted
0..n: Zero or more elements permitted
1..1: Exactly one element permitted
1..n: One or more elements permitted
CONTEXT STRUCTURE AT RUNTIME: CARDINALITY PROPERTY ( 1 )
The context node N1 has the cardinality value c = 0..1. N2 has the cardinality value c = 1..1. These nodes are created under the context root, which itself has a cardinality value c = 1..1. Cardinality describes the maximum and minimum number of elements that the node collection may hold at runtime.
The context root node is instantiated automatically at runtime. The reference to this node is provided by the framework through the controller attribute WD_CONTEXT.
Independent nodes are defined as direct children of the context root node. They are instantiated automatically when accessed for the first time.
CONTEXT STRUCTURE AT RUNTIME: CARDINALITY PROPERTY ( 2 )
The structure of the context at runtime is no longer the flat, two-dimensional hierarchy seen at design time.
The context now comprises multiple dependent objects. At runtime, you can append multiple elements to a collection originating from a context node.
This concept mimics the differences that an internal table exhibits at design time and at runtime.
LEAD SELECTION INDEX
The attribute LEAD_SELECTION_INDEX of each context node is used to simplify the access to the node’s collection. If the context node propertyInitialize Lead Selection is set to true, the attribute is automatically set to 1 as soon as the first element is created. You can also set the lead selection index using the program source code or through user actions related to user interface elements.
LEAD SELECTION - IMPORTANT CASES
You can use special methods in the controller source code to access the value of a node’s lead selection index, as well as the element related to this index.
The lead selection index is used in certain important situations.
If a single row is selected in a table, the lead selection index is automatically adjusted accordingly and you can access the related context element without the element index. The marked row can be manipulated programmatically by changing the lead selection index.
You can bind form fields to attributes of a context node having the cardinality 0..n or 1..n. You can change the lead selection index to programmatically manipulate the displayed data set.
Special methods, such as supply functions, can be assigned to context nodes. These functions are called automatically by the framework if the lead selection in the parent node changes.
CONTEXT STRUCTURE AT RUNTIME: SINGLETON PROPERTY ( 1 )
The context node N1 is the parent node, which has a child node called N2.
The N2 node is a distinct node with its own element collection.
If the N2 node has its singleton property set to false (that is, the node N2 at runtime is a nonsingleton, which is the default), then every element in the parent node N1 is complemented by a distinct instance of the child node N2.
Note that the arrows pointing to each of the N2 node collections originate in the elements of the parent node. Hence, for n elements in the parent node, you will see n distinct instances of a nonsingleton child node.
CONTEXT STRUCTURE AT RUNTIME: SINGLETON PROPERTY ( 2 )
If the Singleton property is set to true for node N2, then despite the multiple elements present in the parent node collection N1, the node N2 is a singleton at runtime. In other words, there will only be one instance of the child node N2.
REPOPULATING A DEPENDENT NODE ( HERE SINGLETON NODE ): SUPPLY FUNCTION
Supply functions are mechanisms used for automatically repopulating child nodes. The property Supply Function has the value GET_N2_DATA. You assign a supply function to each context node of a controller, by setting this value accordingly.
The Web Dynpro calls the supply function at runtime if the data of the context node is needed.
SUPPLY FUNCTION: AUTOMATIC CALLS
The Web Dynpro runtime automatically calls the supply function under certain conditions:
If the node’s collection is initial.
If the lead selection index of the parent node is changed.
If the node’s collection is invalidated programmatically.
Context mapping allows a controller (typically a view controller) to access data that was preprocessed by some other controller. You can drag and drop the context node to the target node. The mapped node then appears as a child node. This mapping relationship allows a direct reference to data in another controller. This obviates the need to copy or move the data.
The context node that acts as the data source is the mapping origin node; whereas, the context node that is mapped is the mapped node.
You can view the mapping path in the property of the node.
CONTEXT MAPPING: INTERNAL MAPPING
If both the mapped node and the mapping origin node lie within the boundaries of one component, the mapping relationship is known as internal mapping.
The mapping relationship is fully established when writing the current component.