Context at design

2
© SAP AG 2005, ABAP Web Dynpro
The structure of the context
Context mapping
Internal mapping
Contents:
The Context At Design Time

3
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
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.
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
You can create the various different nodes and attributes from which a context is
constructed.
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
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.
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
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
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
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.
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
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.
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
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.
Design Time
Context Root
0
Default
Element
The runtime structure of the
context if node BOOKINGS is a
non-singleton.
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
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.
PRICE
Context Metadata
CARRID
CONNID
FLDATE
Context Metadata
BOOKINGS (c=0..n, s=true)
BOOKID
CUSTOMID
CLASS
PASSNAME
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
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.
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
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.
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
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.
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
Context Mapping
Structures of a context can be mapped to other controllers.
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
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.
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
You should now be able to understand:
The Structure of the Context
Internal Context Mapping
The Context At Design Time: Summary

Context at design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Context at design

Similar to Context at design (20)

More from Kranthi Kumar

More from Kranthi Kumar (14)

Context at design