Context Mapping 

Basics

Context nodes and attributes can reference type-compatible nodes and attributes in other non-view contexts (such as component or customer contexts). In this way, such context data that should be displayed in different views using data binding can be saved in a single cross-custom context. This approach enables applications to be modified more quickly and at the same time ensures data consistency. In context mapping, the actual context data is saved only once in the original node. All other context nodes that are mapped to this original node reference the same contents, without having to save it again, for example using copies. In this way, inconsistent context contents are avoided.

The concept of context mapping enables you to better structure your Web Dynpro applications and to implement later functional enhancements or changes more easily. If, for example, an input field should also be displayed in a different view, then a few mouse clicks are sufficient without you also having to adapt the relevant controller code (in the Custom Controller). Application development is responsible for this type of structure in a Web Dynpro application.

Normal Context Mapping

Normal context mapping refers to mapping context elements within a Web Dynpro component. This includes contexts of view, custom, component and component interface controllers. In contrast, mapping across component limits is known as external context mapping.

Mapping Context Nodes

Context nodes can be mapped using different variants. It is an important fact that you can never map to view contexts (local data stores), only to custom contexts (global data stores). These variants are displayed in the following figure:

Context mapping an M node (mapping node) to a different O node (original node) can occur between two controller contexts in the following ways. Variants 1 and 2: Context mapping from view to customer context Variant 3: Context mapping from view to component context Variant 4: Context mapping across several nodes Context mapping to a view controller context is not possible. As local data stores, view contexts are invisible from outside, so that other controller contexts (no matter whether they are view or custom contexts) cannot be mapped to them. Variants 5 and 6: Context mapping cannot be defined from a custom to a view context or between two view contexts.

If an M node (“mapped node”) is mapped to an O node (“original node”), then M maps its node collection to the O’s nodes. The content of mapped nodes is therefore always defined by the node selection of its original node. Context nodes therefore have a list of selected node elements through node selection.
How does the node selection behave with mapped context nodes?
When you define the mapping, you can define that the node selection is mapped as well. Alternatively, it is also possible that the mapped M node is given its own node selection with respect to the node element saved in O. This typically applies to mapped nodes in view contexts, where the node selection corresponds to the data that was selected by the user. This node selection by the user is independent of the one that was defined for the original node for programming reasons.

In context mapping, the mapping of the node selection can be defined using the mappingType-property in the Context Editor:

·        mappingType = collection_only: The mapped context node keeps its own node selection.

·        mappingType = collection_and_selection: The node selection of the mapped context node M references the node selection belonging to original node O. This means that the cardinality of the node selection of the mapped node cannot be edited.

Note the following restrictions when you define a mapped context node:

Property	Description
Node Collection  (cardinality)	The cardinality of the mapped node M matches that of the original node O.
Node Selection (selection)	This property can only be changed if there is no node selection mapping (mappingType= collection_only). If the M node overwrites the cardinality of the O node selection, then the same rules apply to the node selection of the mapped node M as to the definition of the node selection relating to the cardinality of the node collection (see Lead Selection and Node Selection).
Singleton and non-singleton nodes (singleton)	M’s singleton property matches that of O except when an independent M node is mapped to a dependent O node of type non-singleton. As an independent node, M is always of type singleton.