Context

Context

The data used in the component or in the view is stored in the context. Read-write access to this data is available using the controllers as a starting point.

Structure

The data from the contexts is managed in a hierarchical structure. Each context has a root node, underneath which the individual data fields (attributes) are stored in a tree structure. You create this tree structure according to the structure of your application.

Each context node contains data fields that can display the following:

• An individual instance of an object type
• A table of instances.

When a node is created in the context of a Web Dynpro component, the cardinality of the node is specified. The cardinality defines how often a node is to be instantiated at runtime, that is, how many elements of this node are available at runtime. The following table summarizes the possible cardinalities for a node:

Cardinality	Meaning
1:1	Only one element is instantiated.
0:1	The node contains only one element instance, which must not be instantiated.
1:n	n elements can be instantiated, but at least one element must be instantiated.
0:n	The number of instantiated elements of the context node can vary.

Example of Cardinality

The context node Vehicle is used to describe the fleet of a car rental company. It has the cardinality 1…n and is filled from a database table. A number of attributes of this node have a specific value for each vehicle.

The database table indicates that the company owns three vehicles, each with unique registration dates and unique license plate numbers. Thus, to display this table in the Web Dynpro application, 3 elements of the context nodeVehicle must be instantiated; the cardinality of the node must therefore be 0…n or 1…n. (If the Vehicle node is to be filled with values in the context of another function, for example, from a table of all currently available cars, cardinality 0…n should be used since this table could very easily be empty, that is, if all cars are rented out.)

At runtime, the Vehicle context node should contain three elements and appear as follows:

As well as these attributes, a context node can also contain additional child nodes:

For each customer of a car rental company, the two attributes rented from and rented till are listed in the context. At runtime, the context then contains the additional relevant values:

Recursion Nodes

Dynamic node nesting is possible within a context, creating what is called a recursion node. The node that is used for recursion is always a predecessor of the new node. The newly created recursion node is a reference to a predecessor node and therefore cannot be processed separately. Instead it takes on the structure of the node to be repeated.

Context Mapping

Use

Web Dynpro controllers are independent programs that never normally share information with each other. To achieve access to the context of another controller, that controller must be declared as Required Controller .

Note

Remember the guiding principles of Model View Controller (MVC) design. Only non-visual controllers can serve as data generators. View controllers can only serve as data consumers.

More information: Controllers Having No Visual Interface

Information held in the context of a non-visual controller can be made accessible to the context of another controller (view or non-visual) by a technique known as context mapping. Using this technique, two or more controllers can access the same runtime data.

When a mapping relationship is declared the context node acting as the consumer of data is known as the Mapped Node , and the context node acting as the data source is known as the Mapping Origin .

Note

A mapped node can only refer to a single mapping origin node; however, a node acting as a mapping origin can be referred to by many mapped nodes.

Mapping Mechanism

Before a mapping relationship can be established, the following two criteria must be met:

• There must be a suitable node available to act as a mapping origin
• A context node must exist in the consuming controller

All context nodes are runtime objects that contain, amongst other things, a collection. When a mapping relationship is declared, the node collection of the mapped node is replaced by a reference to the node collection in the mapping origin node. In this manner, context mapping never causes data to be duplicated. There is only one copy of the data, and it lives in the collection belonging to the mapping origin node.

Now, when the coding in a view controller accesses the data in a mapped node, it has full read/write access to the data in the mapping origin node, as if it were accessing a node in its own local context.

Note

It is perfectly permissible to create a context node that contains a mixture of mapped and unmapped attributes. In fact, this is a good design because even though data appears to belong to a single node, the attributes that hold the business data are mapped (i.e., they function as consumers of data from a non-visual controller), and the attributes holding data only concerned with the display of the business data are not mapped.