Controllers are the active parts of a Web Dynpro application. They define how the user can interact with the Web Dynpro application. The data that a controller can access is defined in the corresponding context. Different instances of controllers and contexts exist within a Web Dynpro application. In addition to view controllers, which control the behavior of an individual view, there are also global controllers that offer more general services for all the views of a component.
A view controller and the corresponding context exist at least as long as the view is displayed in the browser; if the view is replaced by a subsequent view, the local data is no longer available. However, the lifetime can also be connected to the lifetime of the surrounding component.
A view may be visible in the technical sense as part of a view set, although its content on the screen may be a hidden tab in the background, for example. In this case the view data are still available as before, and the view exists.
Each Web Dynpro component additionally contains at least one global controller that is visible within the component for all other controllers. Once the data for this component controller have been created the first time they are accessed, the lifetime extends to cover the whole period during which the component is in use.
You can add additional global controllers in the form of custom controllers. These also last as long as the component and the data they contain are available to all views of the component.
Every time there is a Web Dynpro window, a further global controller – the Window controller – is added to the component.
Each Web Dynpro component contains exactly one component controller. This controller is a global controller that is visible also outside the component. It is thus part of the interface of a Web Dynpro component.
Communication from one controller to the next is achieved by calling methods from a different controller, or by triggering an event on which other controllers are already registered. You define these controller uses when you create a controller.
Each controller contains program areas in which you can insert your own source code. Therefore, an Application Programming Interface (API) exists for the processing of context nodes and their attributes and data. The necessary initialization of nodes can also be executed using this API. There are further APIs available, for example, the server abstraction layer for accessing the system environment, and the APIs for message handling and dynamic programming.
Controllers can contain their own source code in the following areas:
· Event handlers – these are executed when a view is initialized, ended, or entered, when a user interface element of a view triggers an action, or when other controllers trigger a registered event.
· Methods – these can be called by other controllers
· Supply functions – these are executed when necessary to initialize elements in the context