Controller
Concept
Controller Classes Inside a Web Dynpro Component
The following four controller types can be contained in a Web Dynpro Component (see figure above):
1. Component Controller: Every component contains a single component controller by default. It has no visual interface and can be seen as a component’s master controller.
2. Custom Controller: A custom controller is an optional controller (0..n) inside a component having no visual interface. It is there for implementing specific application logic concerns (value help listeners, configuration) inside a separate controller and outside the component controller.
3.
Window
Controller: A window controller
implements the presentation logic of its related window (0..n, visual
interface). The presentation logic mainly deals with handling or firing
navigation events (inbound and outbound plugs, startup and exit plugs, suspend
and resume plugs).
A window controller can additionally implement one or many component interface
view controllers defined in local or standalone component interface
definitions.
4. View Controller: A view controller implements the presentation logic of its related view (0..n, visual interface). The presentation logic of a view mainly deals withs firing navigation events (inbound and outbound plugs) or dynamically modifying view layouts in wdDoModifyView() and handles action events, validates user input or simply delegates method calls to window-, custom- or component controller.
Controller Implementation
The complete implementation of a Web Dynpro controller is distributed across three different places (see next figure):
1. Controller class: Partially generated class comprising the application defined (self-implemented) logic or source code within user code areas. This is the only controller class an application developer implements source code.
2. Internal controller class: Every Web Dynpro controller class is associated with an internal controller class named Internal<controller name>.java. This fully generated class acts as a mediator between the controller class and the Web Dynpro Java Runtime or other controller classes. It does not comprise any code implemented by the application developer but delegates to it.
3. Web Dynpro Java Runtime implementation: The Web Dynpro Java Runtime implements generic controller functionality which can by accessed via special IWD<Controller>-APIs
Controller Class With User Code Areas
For every listed controller type a corresponding Java class file <controller name>.java is created by the Web Dynpro Tools (figure above, point 1). Within the User Code Areas of this controller class the application developer can implement the required custom code. All code and JavaDoc areas are delimited with the lines //@@begin and //@@end:
Controller Class With User Code |
//@@begin javadoc:wdDoInit() /** Hook method called to initialize controller. */ //@@end public void wdDoInit() { //@@begin wdDoInit() //@@end }
//@@begin others //@@end |
Additional Custom Code Block
At the end of a controller class file the //@@begin others - //@@end code section can be used for any Java code that is not to be visible to other controllers/views or that contains constructs currently not supported directly by Web Dynpro such as inner classes, private methods or member variables etc. The content of this section is in no way managed or controlled by the Web Dynpro Designtime or the Web Dynpro Runtime.
It is important to understand, that the full functionality of a Web Dynpro controller is only partially implemented within the visible controller class comprising the application defined logic (User Code Areas). Many additional functions are implemented within the internal controller class and within the Web Dynpro Java Runtime itself. You can access these functions in your custom code via the special shortcut variables wdThis and wdControllerAPI.
Using Other Java Classes and Interfaces
You can easily use additional Java classes or interfaces within a Web Dynpro controller class. These Java classes are not generated by the Web Dynpro Generation Framework and must completely be implemented by the application developer:
● Java Classes stored in the same Web Dynpro Development Component: Custom Java classes or interface files must be stored under the folder src/packages. This source folder is on the build path of every Web Dynpro DC by default.
● Java Classes stored in another Web Dynpro Development Component: Custom Java classes and interfaces can be exposed within the public part of another DC. By adding a corresponding DC dependency to your Web Dynpro DC you can use these Java classes within all controller classes.
More Information
● Controller Interface Concept
● Example: Implementing a Component with its Controllers and Interfaces