Cross-Component Context Mapping described the mechanism of a mapping across the borders of a Web Dynpro component. In the example, component A used a component B and for Node 1 of the component controller context of A a mapping was defined to the node of the same name of the interface controller context of component B. Both components are known at design time. For a better understanding, the figure below again shows the simple context mapping as explained in the section above:
The mapping definition at runtime provides component A with the value for its component controller context from the interface controller of component B – with other words:
The node of the interface controller context is the “source” node in this mapping relationship.
One example of this type of mapping is the use of a dark component. Such a component does not have its own UI but is used solely for providing for a used component in which a layout is defined.
In case of the external context mapping the flow of information is vice versa:
The used component B defines in its interface controller context a node that is released for an external context mapping. In the controller editor, this is described with the attribute Input Element (Ext). when you create a node for the interface controller. This attribute is available explicitly only to context nodes of the component controller that are marked as interface nodes.
A node of the interface controller context marked in such a way can be linked with a context node of a used component and then receives the relevant values from the context node of the using component A only at runtime.
In this case, Node 1 of the component controller of component A is the “source“ node and at runtime determines the values also for the node with the same name of the interface controller context of component B.
A simple context mapping is always defined in the context of the relevant controller. The relevant controller always belongs to the component you currently edit. The mapping path is always directed from the currently edited controller context to the controller node of the used interface controller.
Contrarily, an external context mapping is always defined in the controller context of the respective component usage. You always define an external mapping for an appropriate node of an “external” interface controller you use. The mapping path in this case always points from the context of the used interface controller to a node in the currently edited controller context.
An external context mapping to a context of a used component makes sense whenever the used component is intended to provide a frequently used UI schema for various other components.
Usually, the node to be mapped externally is fully typed during creation. You already determine at design time which nodes and attributes the externally mappable node contains. This is of advantage because it allows you to program references to this node statically within the relevant controller. These references include linking a UI element to the node.
Example
Within a large application a component is designed for address display. The context from which the address will be selected is completely open at design time, the content of a model belonging to the address display is unknown. However, since the address component is intended to display only addresses from one country, the view layout can be created. Thus you are able to construct a component for the display of country-specific addresses and bind the UI elements to externally mappable nodes. This component may now be used by all kinds of other components; by setting up an external mapping, the address display is supplied with the relevant data.
You are not allowed to set up both a normal and an external mapping for the same controller usage. The resulting mapping would be cyclic and cause runtime errors.
Difference Between Normal and External Context Mapping
The question of whether or not to use an external context mapping cannot always be answered uniquely. From the technical point of view, the desired result can frequently be reached via a normal mapping, provided that the application is redesigned accordingly. However, there is a fundamental difference:
· As soon as you set up an external mapping for an externally mappable node, the runtime call of a supply function you may have explicitly coded is skipped. From this moment on the node is supplied with attribute values exclusively via the node of the using component.
Advanced Concepts
When you create the node to be mapped externally, you can leave open the type. In this case, the node receives its complete typing from the context node for which a mapping is defined to external nodes. Against such a node, you can program only dynamically in the related controller, because its structure is unknown at design time (see Part 3: Dynamic Programming).
If the node to be mapped externally of the used component requires a particular structure, this structure must be contained in the context node of the using component (A in our example). In addition, this node can contain other attributes, which are not known to the interface controller of component B at design time. In this case, the interface controller of component B can be coded
· statically against the given structure, and additionally
· dynamically in view of attributes that may be added via a mapping.
A node, for which an external mapping has been defined, can no longer use the dispose method.
No comments:
Post a Comment