Controllers Having No Visual
Interface
Controllers that have no visual interface are generically known as non-visual controllers. The highlighted areas in the figure below show the controllers in a Web Dynpro component that have no visual interface. As is to be expected, all these controllers are located entirely on the Programmatic Entities side of the diagram.
Structure of Non-Visual Controllers
All non-visual controllers have the following structure:
Usage Declaration of Required Controllers and Model Objects
In order to gain access to the data and functionality found in other Web Dynpro coding entities, usage declarations must be made. These declarations are represented by the three boxes down the left of the figure above:
● Other non-visual controllers within component
All Web Dynpro controllers are independent programs in their own right. Therefore, if access is required to data or functionality found in another controller (within the same component), then a specific usage declaration must be made. Only after this declaration has been made is it possible to access the data and functionality found in the other controller. Data is shared between controllers by means of a mechanism known as context mapping.
There are two important points to be made about the usage declarations between custom controllers. A non-visual controller is only permitted to:
○ declare the use of another non-visual controller
○ declare the use of another non-visual controller within the same component
It is not permitted to declare the use of a view controller as a required controller as this would violate the principle that view controllers are only permitted to act as consumers of data, not generators.
● Other components
In order to maximize code reuse, atomic units of business functionality should be packaged into components. Then, in order to make use of these reusable units of code, one component can declare the use of another component. This forms a parent child relationship between the two components, with the child’s interface controller being the point of interaction.
As soon as the component acting as the parent, declares the use of the child component, the parent component controller has access to all the data and functionality found in the child component’s interface controller.
● Models
Model objects are created independently from Web Dynpro components. However, once a model object has been declared for use (at the Web Dynpro component level), all controllers within the component have implicit access to the data and functionality found within it.
Implementation
The implementation of any Web Dynpro controller will always contain a standard framework of generated code, within which are sections of code written by the developer at design time.
· Hook Methods
The standard hook methods act as a static interface between the Web Dynpro framework and the coding written by the application developer. These hook methods may not be renamed or modified in any way; however, the Web Dynpro developer will frequently need to insert their own coding into these methods.
The Web Dynpro developer is not responsible for explicitly calling any of the hook methods. That job is performed by the Web Dynpro framework. They will be called automatically by the Web Dynpro framework at predefined points in time such as component initialization, and just prior to the controller’s end-of-life (to name only a few).
· Other Methods
The Web Dynpro developer may declare the existence of any methods they feel necessary for the completion of their business task. Such methods will never be called directly by the Web Dynpro framework, but the developer may insert calls to their instance methods from coding they have added within one of the standard hook methods.
· Events
Events are declared runtime objects that represent standard server side triggers for invoking subsequent business processing. An instance method may be declared to act as a handler for such an event.
UI element events are always handled within their own view controller; there is no cross-controller communication. UI element events themselves are predefined and cannot be changed.
Data Storage Area (Context)
Irrespective of its type, every Web Dynpro controller has a data storage area known as the context. This is a hierarchical repository within which all runtime data used by the controller is stored. The metadata used to define the structure of the context is typically defined at design time, but can also be defined dynamically at runtime.
As soon as the controller instance reaches the end of its lifecycle, then all the data in its context is lost. It is incumbent upon the Web Dynpro developer to write the necessary coding to store all required context data before the controller reaches this point.
More Information
● Contexts