Context at design
1 like592 views
1. The document discusses the structure and usage of contexts in Web Dynpro controllers. Contexts are hierarchical data storage structures that hold runtime data for the lifespan of a controller. 2. Contexts are constructed from nodes and attributes at design time. At runtime, nodes become collections that can contain multiple elements. Singleton nodes ensure efficient data access by only loading child node data when needed. 3. Context mapping allows controllers to access each other's context data, sharing it without copying. Internal mapping refers to a mapping within a single component.
Context at design
- 2. 2 © SAP AG 2005, ABAP Web Dynpro The structure of the context Context mapping Internal mapping Contents: The Context At Design Time
- 3. 3 © SAP AG 2005, ABAP Web Dynpro After completing this lesson, you will be able to: Understand the structure of the context Use the context editor Use internal context mapping The Context At Design Time: Objectives
- 4. 4 The Context Every Web Dynpro controller has exactly one hierarchical data storage structure known as a context. The data held in the context exists only for the lifespan of the controller. Once the controller instance has been terminated, all data held within its context is lost. Context structure The structure (I.E., the metadata) of a context will typically be defined at design time; however, at runtime, it is perfectly possible not only to modify the contents of the context, but also to modify its structure. Data visibility Unless declared to be otherwise, all runtime data within a controller’s context is private to that controller. Sharing data between different controllers Information held in the context of a custom controller can be made easily accessible to the context of another controller (view or custom) by a technique known as context mapping. Using this technique, two or more controllers can access the same runtime data. This is the primary mechanism for sharing data between controllers within a single component. It is not permitted (and not possible) for a view controller to share its context data. © SAP AG 2005, ABAP Web Dynpro The Context - The Heart of a Controller Controller Implementation Standard Hook Methods Instance Methods Context Root Node Required Controllers Controller Interface Other WD Controllers Custom Controller Business Logic (Models) Created by explicit declaration or coding Created by the Web Dynpro Framework (WDF) Component Usage Other WD Components
- 5. 5 You can create the various different nodes and attributes from which a context is constructed. © SAP AG 2005, ABAP Web Dynpro Changing the Context 1) Open a controller (view or custom) using the Change option in the context menu 2) Choose the Context tab. 3) Display the Property by selecting the CONTEXT node
- 6. 6 Context Structure All controller contexts are constructed from a hierarchical arrangement of entities known as nodes and attributes. A context always has a parent node known as the Root Node. The root node is created automatically when the controller is initialised and always has the same properties. Important: The context root node may not be deleted or modified in any way! Nodes A context node is the main abstraction class used for runtime data storage within the Web Dynpro Framework. Context nodes are arranged hierarchically and are permitted to have children. The node may have attributes or other nodes as children. All the child entities of a node are aggregated into a unit known as an element. A node can then be thought of as a collection of such elements in the same way that a table is a collection of rows. The maximum and minimum number of elements permitted in a node collection is controlled by the cardinality property. All nodes contain an element collection, even if the maximum number of elements within the collection is limited to one. Attributes An attribute is a hierarchical entity within the context that is not permitted to have children. A context attribute cannot exist without being the child of some parent node – be it the context root node itself, or some other node. © SAP AG 2005, ABAP Web Dynpro Context Structure – Design Time (1) Context Root Node Node Attribute Context menu on the Context Root Node Context Node: Are arranged hierarchically and are permitted to have children Children of a node may be entities known as other nodes or attributes Metadata description declared manually or derived from a Dictionary Structure Context Attribute: Stores runtime data or references to runtime data Based on DDIC Types
- 7. 7 The Context at design time At design time, you are creating the metadata structure within which the runtime data will live. The diagram above gives the impression that the context structure is a flat, two dimensional tree, much like the display of directories and files shown in the Windows™ Explorer. However, all context nodes are collections, so there could potentially be multiple instances of each child node and attribute within a node’s collection. The Cardinality Property Every context node has a property called Cardinality. This property is composed of two values that taken together, describe the maximum and minimum number of elements the node collection may hold at runtime. Cardinality Minimum: 0 or 1 Cardinality Maximum: 1 or n Therefore, there are four possible cardinality values (specified as <Min>..<Max>) 0..1 Zero or one elements permitted 0..n Zero or more elements permitted 1..1 One and only one element permitted 1..n One or more elements permitted © SAP AG 2005, ABAP Web Dynpro Node Metadata (c=cardinality, s=singleton) IF_WD_CONTEXT_NODE_INFO (interface) Attribute Metadata (data type) WDR_CONTEXT_ATTRIBUTE_INFO (structure) Context Structure – Design Time (2) All context nodes are collections. A node collection is composed of elements, where an element is an aggregation of the node’s immediate children (attributes and/or other nodes). The cardinality property controls the number of elements a node collection may hold at runtime. Design time A node collection Context Root (c=1..1, s=true) FLIGHTS (c=0..n, s=true) PRICE Context Metadata CARRID CONNID FLDATE Context Metadata BOOKINGS (c=0..n, s=false) BOOKID CUSTOMID CLASS PASSNAME
- 8. 8 The Context Root Node The context root node always contains exactly one element (notice the cardinality is 1..1). This is known as the default element and it cannot be deleted! Violating the cardinality constraints If you attempt to perform any action on a node collection that would violate its cardinality, then you will get a runtime error from the Web Dynpro Framework. Such actions would be: trying to delete the default element from a node of cardinality 1..<something>, or trying to add a second element to a node of cardinality <something>..1. © SAP AG 2005, ABAP Web Dynpro Context Structure – Runtime (1) All independent nodes are forced to be singletons. This is because the context root node has one and only one element. c=1..1, s=true Independent Node 1Default Element c=0..1, s=true Independent Node 1 Context Root Node c=1..1, s=true 1Default Element = Element created by an application at runtime = Element created by the WDF at context initialisation time Node collection is initially empty. Can contain a maximum of one element. Node collection contains a default element. Can contain a maximum of one element.
- 9. 9 Three dimensional context You can now see that the structure of the context at runtime will not be the flat, two dimensional hierarchy seen at design time. Instead, a context node takes on depth. If you think of the design time structure as occupying the x-y plane, then at runtime each element in the node collection occupies a position in the z plane (moving into and out of the page). Lead Selection A node's element collection can be accessed using a 1 based index value. It is possible to flag multiple elements as being selected (controlled by the selection cardinality property), but only one of the selected elements can be processed at any one time. The element being processed is referred to as the lead selection element. © SAP AG 2005, ABAP Web Dynpro Context Structure – Runtime (2) Context Root Node c=1..1, s=true 1Default Element = Element created by an application at runtime = Element created by the WDF at context initialisation time Node collection is initially empty. Can contain as many elements as required. Node collection contains a default element. Can contain as many elements as required. = Element at the lead selection c=0..n, s=true Independent Node ..n 2 1 c=1..n, s=true ..n 2 Independent Node 1Default Element All independent nodes are forced to be singletons. This is because the context root node has one and only one element.
- 10. 10 The Singleton property of a context node Notice that the context node FLIGHTS has a child node called BOOKINGS. The BOOKINGS node is a distinct node with its own element collection. The Boolean property called Singleton critically affects the relationship between an dependent node and its parent node! Node BOOKINGS as a non-singleton (Singleton = false) If the node BOOKINGS has its Singleton property set to false, then for every element in the parent node collection (FLIGHTS in this case), there will be a distinct instance of the child node BOOKINGS. The most important thing to understand here is that each instance of node BOOKINGS is related to the respective element in the parent node collection. Notice that the arrows pointing to each of the BOOKINGS node collections originate from each element in the parent node. Therefore, if there are n elements in the parent node, then there will be n distinct instances of a non-singleton child node. © SAP AG 2005, ABAP Web Dynpro Context Structure – Runtime (3) Design Time Context Root 0 Default Element The runtime structure of the context if node BOOKINGS is a non-singleton. Context Root (c=1..1, s=true) FLIGHTS (c=0..n, s=true) PRICE Context Metadata CARRID CONNID FLDATE Context Metadata BOOKINGS (c=0..n, s=false) BOOKID CUSTOMID CLASS PASSNAME ..nCARRID CONNID2CARRID CONNID1CARRID CONNID FLDATE FLIGHTS BOOKINGS ..nBOOKID CUSTOMID2BOOKID CUSTOMID1BOOKID CUSTOMID BOOKINGS ..nBOOKID CUSTOMID2BOOKID CUSTOMID1BOOKID CUSTOMID BOOKINGS ..nBOOKID CUSTOMID2BOOKID CUSTOMID1BOOKID CUSTOMID Runtime
- 11. 11 Node BOOKINGS as a singleton (Singleton = true) If the node BOOKINGS now has its Singleton property set to true (which is the default), then it does not matter how many elements are present in the parent node collection (FLIGHTS in this case), there will only ever be one instance of the child node BOOKINGS. Repopulating singleton child nodes In the above example, there could be many different elements in the FLIGHTS node collection. However, since there is only ever one instance of the singleton child node BOOKINGS, we need to ensure that when this child node is accessed, it contains the correct data for the selected element in the parent node. Supply functions Supply functions are the mechanism to repopulate child nodes when the lead selection in the parent node changes. When a singleton child node is declared, you must also write an accompanying supply function. The Web Dynpro Framework will then automatically call your supply function when the lead selection in the parent node changes. © SAP AG 2005, ABAP Web Dynpro Context Root (c=1..1, s=true) FLIGHTS (c=0..n, s=true) PRICE Context Metadata CARRID CONNID FLDATE Context Metadata BOOKINGS (c=0..n, s=true) BOOKID CUSTOMID CLASS PASSNAME Context Structure – Runtime (4) Design Time Context Root 0 Default Element The runtime structure of the context if node BOOKINGS is a singleton. BOOKINGS ..nBOOKID CUSTOMID2BOOKID CUSTOMID1BOOKID CUSTOMID Runtime ..nCARRID CONNID2CARRID CONNID1CARRID CONNID FLDATE FLIGHTS
- 12. 12 Why do Singleton nodes exist? When a typical business transaction is being used, information will often be presented in the form of a list of header records of some sort; for instance, sales order headers. From this list, the user will typically select one order header and then look at its line items. It makes much better sense to read the line item information only when it is needed, rather than to read all the line items for all the sale orders in the hope that the user might want to look at the information! This would be a highly inefficient application architecture both in terms of processing requirements and memory usage. Lazy Data Access Web Dynpro follows the principle of Lazy Data Access. This means that data is only obtained when it is actually needed. When this principle is applied to the architecture of the context, it means that unless the program actually needs to look at the data in a child node, then that child node will remain unprocessed. Hence, there is no need to hold multiple instances of data the user has not requested. Having singleton child nodes greatly reduces the amount of memory required for a business application, and means that the Web Dynpro application does not waste time by performing unnecessary processing on business data the user does not want to see. © SAP AG 2005, ABAP Web Dynpro Context Structure – Why Singleton nodes? Context Root 0 Default Element Q: Why do singleton nodes exist? A: Efficiency! This design of context structure both copies the way users handle business data, and causes the Web Dynpro application to consume significantly less memory. BOOKINGS ..nBOOKID CUSTOMID2BOOKID CUSTOMID1BOOKID CUSTOMID ..nCARRID CONNID2CARRID CONNID1CARRID CONNID FLDATE FLIGHTS
- 13. 13 Supply Function Each context node of a controller can be assigned a supply function. This supply function is called by the runtime when the data of the context node is used. This is the case when a UI element is to be displayed for the first time with the data of the corresponding context, for example. In general, the supply function is called when one or more elements of a context node are accessed and when the context node is not filled yet or is initial, or the context node has been invalidated in a previous step. Supply Functions of Singleton Nodes The supply function is especially useful in combination with singleton nodes: The values of sub node elements of the type Singleton depend on the element of the parent node to which the lead selection is currently assigned. If the lead selection is changed by the user, the supply function can access the new lead selection element and recalculate the values of the sub node elements accordingly. © SAP AG 2005, ABAP Web Dynpro Supply Function Context node can be assigned a supply function This supply function is called by the runtime when the data of the context node is required Especially useful in combination with singleton nodes Context Root BOOKINGS ..nBOOKID CUSTOMID2BOOKID CUSTOMID1BOOKI DCUSTOMID ..nCARRID CONNID2CARRID CONNID 1CARRID CONNID FLDATE FLIGHTS Supply function BOOKINGS_READ
- 14. 14 Context Mapping Context mapping allows a controller (typically a view controller) to access data that has been pre-processed by some other controller. Since a mapping relationship allows a direct reference to be made to data in another controller, there is no need for this data to be copied or moved. Important: A mapped node ceases to maintain its own element collection! Instead, it references the element collection of the mapping origin node. Why can a view controller not act as a data source for a mapping relationship? According to the principles of good MVC design, a view controller should be written in such a way that it takes no part in the generation of the data it displays. Instead, the view controller should only be concerned with displaying pre- generated data and then handling the resulting user interaction (validation and error handling etc.). It is the custom controller’s job to interact with model objects to generate the required data. Once the data has been generated, the custom controller then supplies it to a view controller for display. If a view controller were allowed to act as the data source (origin) for a mapping relationship, then the situation could be created in which a custom controller was dependent upon functionality found in a view controller. This would be bad MVC design and is therefore not permitted. © SAP AG 2005, ABAP Web Dynpro Context Mapping Context mapping is the primary mechanism for sharing data between different controllers. Advantages: Data is automatically available to all controllers using the mapping relationship Only one copy of the data is ever maintained Data can be mapped selectively, thus reducing the amount of data in a controller’s context to the minimal set required to fulfil a task
- 15. 15 Context Mapping Structures of a context can be mapped to other controllers. © SAP AG 2005, ABAP Web Dynpro Context Mapping Drag and drop structure or create a node and define the mapping After the mapping the mapped structure appears in the target context In the property of the node the mapping path is visible
- 16. 16 Internal Context Mapping Internal mapping is the name given to a mapping relationship in which both the mapped node and the mapping origin node lie within the boundaries of one component. This means that the mapping relationship can be fully established when writing the current component. There is however, one special case where a mapping relationship can only be partially established when writing the current component. This is known as External mapping. As the name implies, this is a situation in which the mapping origin node lies outside the boundaries of, or is external to, the current component. The External mapping will be discussed later. © SAP AG 2005, ABAP Web Dynpro W e b D y n p r o C o m p o n e n t Context Mapping: Internal Mapping View Controller Component Controller Mapping Relationship Context Root FLIGHTS Mapped node collection Node collection of mapping origin Controller Usage Declaration Context Root BOOKINGS BOOKID CUSTID CLASS PASSN PRICE CARRID CONNID FLDATE BOOKINGS BOOKID CUSTID CLASS PASSN PRICE CARRID CONNID FLDATE FLIGHTS
- 17. 17 © SAP AG 2005, ABAP Web Dynpro You should now be able to understand: The Structure of the Context Internal Context Mapping The Context At Design Time: Summary