View Controllers 

A view controller is the controller within a Web Dynpro component that handles both the presentation of business data, and responses to user input. This covers all aspects of data presentation, and calling action handlers in response to user input. A view controller is always considered to be a consumer of data; therefore it cannot be nominated as a “Required Controller” by any other Web Dynpro Controller.

The context of a view controller cannot be used to hold persistent data. Once a view controller is no longer a member of the current View Assembly, then the view controller instance and all its data is lost.

All controllers that have a visual interface conform to the following structure.

Required Controllers

As per the “Required Controllers” for a custom controller, a view controller may declare the use another custom controller within the same component in order gain access to its data and functionality.

Model Usage

Although it is technically possible, it is considered poor design for a view controller to interact directly with a model object. Should you find yourself needing to write this type of code, then it is very likely that you failed to implement the principles of Web Dynpro Component design correctly.

Component Usage

As per Custom Controllers, a view controller can inherit the use of a child component. Usually however, a view controller will not need to interact directly with a child component instance. However, since the possibility exists for a child component to perform some presentation only related processing, such interaction is technically possible.

Implementation

The implementation of any Web Dynpro controller will contain a standard framework of generated code, plus any sections of code written by the developer at design time.

Standard 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 calling these methods explicitly, that job is performed by the Web Dynpro framework.

Such standard hook methods will be called automatically by the Web Dynpro Framework at controller initialization time, and just prior to the controller’s end-of-life.

Instance Methods

The Web Dynpro developer may declare the existence of any instance 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 the instance methods from coding they have added to one of the standard hook methods.

Actions

Actions are a View Controller specific mechanism for responding to events raised on the client device as a result of user interaction.

Once an Action has been declared, it can then be associated with any number of UI element events. In this manner, it is possible to write one generic action event handler that can respond to various events raised by multiple UI elements.

For instance, you have placed a Button UI element on the view layout, and you wish the server to respond when the button is pushed. The required steps are as follows:

1. Create an Action object in the View Controller. This will cause an action handler method to be created.
2. Place a Button UI element on the View Layout. This UI element is able to raise a client side event.
3. Associate the UI element event with the Action.

As a result of performing these configuration steps, when the Button UI element raises its client side event, a round trip to the server will take place and the associated server side action handler method will be invoked.

Navigation Plugs

Navigation from one view to another is performed using Navigation Plugs. A plug can either be a navigation entry point, known as an “Inbound” plug; or it can be a navigation exit point, known as an “Outbound” plug.

Inbound and Outbound plugs are declared on a per view basis. A plug belongs to a specific view controller and in order for navigation to take place; corresponding inbound and outbound plugs must be associated with each other at design time.

Once this association has been made, the developer should implement the coding in the action event handler method that decides whether navigation is to take place or not (E.G. only perform navigation if all the data received from the user valid).

Since a design time association has already been made between an outbound plug and one or more inbound plugs, it is sufficient for the developer simply to call the method generated by the declaration of the outbound plug. The Web Dynpro Framework then automatically handles the execution of the corresponding inbound plugs in the target views.

Context

Irrespective of its type, every Web Dynpro controller has a data storage area known as the context. This is the hierarchical repository in which all runtime data used 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 the 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.