Context Description 

Overview

Each Web Dynpro controller has exactly one hierarchically structured data store, called the context. The structure of a context is normally defined at design time, and can be modified at runtime (dynamically) if necessary using the associated context API.

Data is added to a context at runtime, either by calling context interface methods or using the context mapping mechanism. In the latter, the elements in one context, known as nodes and attributes, point to the corresponding elements in another context. Context mapping simplifies the task of storing data centrally in a controller context and referencing it from any other contexts.

In a Web Dynpro Controller, the context has the following functions:

• Storage location for structured data:  A Web Dynpro Controller can store local data like Java classes in normal instance variables. Using the controller context as the storage location provides other possibilities, such as data binding (described below) and context mapping at the declarative level.
  In addition to the UI relevant data (values of UI element properties), you can also save as many Java objects (for example of type java.lang.Object) as in a controller context you like, which are not required directly for the user interface.
• Defining UI element properties using data binding: In Web Dynpro, the properties of UI elements are not defined by direct access to the relevant object instances in the view controller. Instead, the UI element properties are bound to context attributes at design time (data binding). At runtime, a bound UI element property therefore has the value assigned to it that is stored in the relevant context attribute. This means that a change to a UI element property on the user interface automatically triggers a change to the property of the corresponding context attribute, and vice versa.
• Displaying tree structures and master-detail relationships
• Automatic data exchange between controllers using context mapping: Mapping relationships can be defined between Web Dynpro controller contexts. This determines that the mapped context does not store its data itself. Instead, the data is stored by means of the context being referenced to another context (the data context). Context mapping therefore works in both directions. When data changes in one context, the data automatically changes in the other context.

• Connection to the back end: A controller context can also be connected to a model interface as the interface to the back-end layer. At runtime, the context then points to the business data (model objects) received from the back-end system. 

The following sections provide further details about the following concepts.

●     Declaration of controller contexts:  Principles of the definition of contexts at design time, supply functions and runtime aspects of controller contexts, singleton and non-singleton nodes, context attributes and the use of the Java Dictionary, calculated context attributes, recursive context nodes

●     Context mapping: Principles, normal context mapping, external context mapping, restrictions, mapping recursive context nodes