Declaration of Controller Contexts 

Context Types

In the Web Dynpro programming model, there is a difference between view controllers and custom controllers. The component controller is a special custom controller that every Web Dynpro component contains as standard. All other custom controllers have to be added declaratively. Custom and view controllers differ from each other in terms of their lifetime and also their visibility. This difference also affects the individual contexts that are contained in a controller.

The data saved in the controller context exists only as long as the Web Dynpro controller exists. All context data is deleted as soon as a controller no longer exists. As a result, it is not possible to use a context without its corresponding controller. 

●     View contexts: A view controller is bound to a view and exists as long as the view in the Web application is displayed. Furthermore, a view’s interface elements can only be bound to the context of the corresponding view controller (data binding). The context of a view is therefore not suitable for saving data that needs to be available within the Web application for several views. View contexts should therefore be regarded as local data stores. They are not visible from outside the program for custom controllers.
View contexts can reference higher-level custom contexts in controllers with a longer lifetime using the concept of context mapping. Once mapped context elements have been defined, no further application coding is necessary. Definition of controller usages in view controllers also enables the program to access custom contexts (IPublic interfaces of custom controllers).

●     Custom contexts: Custom contexts are used to save cross-view data that is globally available. With the exception of the component context, which every Web Dynpro component has as standard, custom contexts have to be defined at design time. Using context mapping, all other controller contexts can refer to contents of custom contexts, without saving the contents themselves. As custom contexts are visible for all other controllers of a Web Dynpro component, they can be viewed as a global data store within a component.

The graphic below shows the visibility concept for contexts in custom and view controllers. Custom contexts are globally visible for all controller types. View contexts are not visible from outside the program; their contexts represent local data stores. The visibility displayed in the graphic has to be defined by application development when it is designed using corresponding controller usages. By default, there is absolutely no visibility between the controllers. B is only visible to A if the use of controller B is defined for controller A, thus allowing context mapping from A to B.

 

 

Structure of the Context

In most cases, the structure of a controller context is defined in the context perspective view of the Web Dynpro tools. This structure can be enhanced dynamically at runtime in special application scenarios using the context interfaces that are provided. At design time, first define the hierarchical structure of a context and the type and structure of its contents at runtime. The relationships between the context definition at design time and context contents at runtime are vitally important for understanding the context concept. These are explained in further detail in the following sections.

A hierarchical context structure consists of nodes and attributes. Context nodes and attributes are known in general as context elements.

●     Nodes: As soon as a controller is declared, its content contains a root node of cardinality 1..1, that is, it contains exactly one node element instance at runtime.
A root node can contain value attributes and/or additional child nodes; in turn, each child node can span any tree structure with additional child nodes and attributes.
A node can be classified as either a value node or as a model node. The difference between value nodes and model nodes is that a value node saves the data itself, whereas the mode node only references an external model object that saves the data.

●     Node elements: All elements (attributes, nodes) directly below a node form a unit called a node element at runtime. At runtime, context nodes are collections (such as a list) of node element instances, known as node elements. The maximum and minimum number of node elements that can be contained in a node element collection at runtime is defined by the node cardinality.
As a context node is a collection of node elements, and not a collection of attributes, an attribute defined below the node at runtime can have several values. Each node element is numbered to address each individual attribute. The element that has just been selected in a node element collection can be accessed using what is called the lead selection.

●     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 at runtime, a context node contains a set of what are called node elements, whereas attributes represent scalable data types only (such as strings, integer values or even Java types such as java.lang.Object).

 

The context as a local mini-database   To get a better understanding of the context, it helps to think of it as a local mini-database within a Web Dynpro controller. As in a database…. ●     the structure of a context is defined at design time and can be changed or extended at runtime, ●     context nodes resemble database tables, ●     context attributes resemble tables columns, ●     node elements resemble table rows, ●     parent-child relations between context nodes correspond to the master-detail relationships between tables; ●     every context node has a lead selection at runtime, in the same way as a database table has a cursor at runtime.

 

●