Context Description 

Overview

Each controller supports a hierarchical data structure that is based on a general root node. The data is known as the context of the controller. The individual nodes in the context are either instances of data objects or collections of node elements. Each node element of the context has the same object type. The object type specifies the property of the context node. If these properties represent a complex data type, they are defined as subnodes in the context hierarchy. The cardinality property of the node determines whether or not a context node is a collection. The cardinality also determines whether or not an element is instantiated.

Each Web Dynpro application can contain one or more controllers. Each application and each view contains at least one default controller. Each controller has exactly one context. This context contains the local data fields, which can also be used for context mapping. Each context instance is directly connected to a controller instance. Due to this mutual dependency, the context must always be used with a corresponding controller.

Context Structure

A context consists of a single root node of the cardinality 1..1. The root node can contain attributes as well as additional child nodes, and each child node can contain any tree structure with additional child nodes and attributes.

The attributes can be considered leaves of the tree structure, which means that attributes cannot contain children. The main difference between nodes and attributes is that nodes are a set of instances of a complex data structure at runtime, whereas attributes are only scalar data types.

A node can be classified as a value node or model node. The difference between value nodes and model nodes is that a value node can store the data itself, whereas the model node only references an external model object that stores the data.

Nodes

At runtime, a node provides the following characteristics, which you can define as characteristics of the context at design time:

• A node contains a collection of elements, known as node elements. These elements contain attributes that are described at design time. You can determine the data type and the cardinality of the collection.
• A node records the selection of its node element colllection. Generally, the selection of multiple elements is possible. However, the lead selection – the selection of an individual element – plays an important role.
• A node is of the collection type List.

Nodes are associated to each other in a hierarchical tree structure.

Node Collection

Nodes can contain a collection of elements with the same structure (set of attributes = node element type). In Web Dynpro, this collection is known as node collection. The elements of the node collection are node elements.

Type	Short Description
List	The data type List describes a sorted group of objects (collection), in which duplicates are allowed. The group enables you to position the objects.

You can define the node element type in the Web Dynpro perspective of the SAP NetWeaver Developer Studio at design time.

The specification of the cardinality indicates the number of possible node elements. At design time, you can determine the cardinality of a node collection, which provides another way of manipulating the behavior of the context node. 

Possible values	Short Description
0..1	The node can be empty or contain one element as a maximum.
1..1	The node contains exactly one element.
0..n	The node can be empty or contain any number of elements.
1..n	The node contains at least one element.

Node Selection

Nodes can qualify a specific part of their node collection. For this, the node selection is used, which is another property of the context node. The cardinality of the selection is specified using the selection property, which you can define in the SAP NetWeaver Developer Studio.

One element of the selection is highlighted as the lead selection. The following applies to the lead selection:

• The controller code of an application program can access the element of the lead selection with little effort.
• The UI elements can be bound to the attributes of this element.
• The content of the child nodes depends on the lead selection of the parent node.

Node selection and lead selection are both node properties that can be bound. Therefore, the UI elements can display and modify this selection.

For example, selected rows in a table represent the selection of the node bound to the table. Selecting or deselecting an element in the table adds or deletes the corresponding element of the node collection.

Possible values	Node Cardinality	Short Description
0..1	Any cardinality	The selection of an element (@ of a lead selection) - can be empty.
1..1	1..1, 1..n only	The selection of an element (@ of a lead selection) – must contain at least one element.
0..n	0..n, 1..n only	Multiple selection of elements – it can be empty, one element is specified as the lead selection.
1..n	1..n only	Multiple selection of elements -  one element is specified as the lead selection.

Independent and Dependent Nodes

The children of the root node are known as independent nodes, all the other nodes are called dependent nodes. Whereas the content of the independent nodes is determined by the application, the content of the child nodes depends on the lead section of the superordinate parent node.

Note that the content of all child nodes becomes invalid when their parent node is bound to a new collection.

Context Types

There are two types of controllers and consequently two types of context types. A view controller is bound to a view and exists as long as the view in the Web application is displayed. UI elements can only be bound to the context of a view to which they belong. This is the reason for the short lifetime of a view context. Therefore, the context of a view is not suitable for storing data to be provided for several views within the Web application. To hold data for a long period, a custom context is used – that is, a context of a Custom Controller. By default, Web Dynpro provides a specific custom context, the Application Context. A Custom Context belongs to the Web application itself and exists as long as the Web application exists.

Mapping

The UI elements of a view can only be bound to the context of this view. The data that should exist for the whole duration of the application, however, can only be provided by a custom context. Instead of copying multiple context structures back and forth, you can map a context node to another: For example, you can map nodes from a custom context in the context of a view. In this way, the context node of the view does not store the data, but references it to a custom node, which contains the data. The data are maintained in the Custom Context, so the context data of a view is kept up-to-date without having to modify the program.

You find detailed information about how to create context nodes and context attributes and about mapping under:

Context Editor

Application of Context Programming and Data Binding.