Mapping Context Attributes
When you define the mapping of context attributes in Web Dynpro tools, you have to distinguish between the following two cases:
- Mapping top-level attributes (below the root node): Only one context attribute of the context root node is mapped to any attribute in the original context.
-
Mapping attributes in context
nodes: In addition to the
mapping definition for a context attribute, there must also be a mapping
definition to which the context attribute belongs. The original attribute OA
does not necessarily have to belong to the context node ON to which the MN
node is mapped. This is known as deep attribute mapping. To determine the value in the context attribute
OA, starting with original node ON, the respective lead selection of the
underlying node is processed until the node element that belongs to attribute
OA is reached.
When context elements are processed, different problems can occur at runtime in the original context that saves the data referenced by mapping:
- Missing node instance: The original node ON is of type non-singleton and the child of a parent node that does not contain any node elements at runtime, or where no lead selection is set. In this case, context mapping cannot be triggered.
- Missing lead selection: No lead selection is set in a node in the original context that is required to trigger the context mapping.
If one of these two problems occurs at runtime, the Web Dynpro runtime environment returns null for read accesses to context attributes. On the other hand, an exception is thrown for write accesses. Note that these problems can also occur with the mapping of context nodes.
Deep attribute mapping
|
In deep context attribute mapping, a context attribute MA that belongs to node MN is mapped to attribute OA in the original context, which does not belong to the original node ON. Instead, the original attribute OA is located in a deeper child node of ON. The value of OA is determined by sequentially processing the lead selection of the lower nodes, starting with the top selected node element. In the example, all nodes in context B are singleton nodes. |
Mapping Example
In this example, the interface contains a view assembly consisting of three views, A, B and C. Data binding: The UI elements it contains, or rather, their properties, are partly bound to the context that belongs to a view (UI elements in view A are bound to view context A and so on). These contexts contain a hierarchy of nodes and attributes for providing the required data in the view. Context mapping: Context elements can point to context elements in other controllers. Data is saved only once, although it can be referenced from different contexts. This ensures that the data consistency is automatically ensured across view limits.
Note that the independent context nodes in view contexts A and B (point (1) in the figure), are both mapped to the same context node (2) in the component context. This means that both nodes (called RecordSet) reference the same list of node elements. |
|
Whereas a table is displayed in view A, only a form of data fields is displayed in view B. The table in view A contains all node elements as table rows, where a row points to the lead selection (3). Three attributes of this currently selected node element are displayed in the form in view B. The mapping of the context nodes (1) in view contexts A and B must also include the mapping of the node selection. The approach that is displayed makes program access to the currently selected node element in the component controller context (2) considerably easier. For the access, it is not necessary to know how the node element was selected in the user interface, whether through the selection of a table row in view A or a selection field in view B. This approach significantly reduces the dependencies between application and presentation logic. |
|
