Custom Controllers 

Custom controllers are similar to the component controller in that they too have no visual interface. However, the existence of custom controllers is controlled entirely by the Web Dynpro developer at design time. Declaring the existence of a Web Dynpro Component causes the component controller to be created automatically, but this is not the case with custom controllers. Custom controllers are only created by an explicit design time declaration.

All custom controllers have the following structure:

All controllers lacking a visual interface are primarily responsible for generating data that will ultimately be supplied to a view controller for display.

Service Controller

A special type of a custom controller is the service controller. While you create a service controller, you can map the context to an existing model (that has to be declared as a used model in your component). In this case the code necessary to access the model is generated together with the controller.

When should a custom controller be used?

Custom controllers should be created only when their presence will simplify the overall structure of the component. The principles to follow for deciding when a custom controller is needed are:

●     Reuse

Create a custom controller if you have identified a reuse case for a specific unit of code required by several other controllers within the component.

●     Task separation

To avoid placing too much coding in the component controller (and thereby potentially increasing its initialization time), place coding dedicated to a specific task into a separate custom controller

Lifespan of custom controllers

The lifespan of a custom controller is determined by a parameter setting made during the design time declaration. It can be either Framework Controlled or On demand.

If you choose Framework Controlled, then the Web Dynpro Framework will instantiate the custom controller when the component is instantiated.

If however, you choose On demand, then the Web Dynpro developer must write the coding necessary to instantiate the custom controller.

Required Controllers

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 custom controller is only permitted to:

·         Declare the use of another custom controller.

·         Declare the use another custom 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.

Model Usage

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 usage of the data and functionality found within it.

Component Usage

In order to maximize code reuse, 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, parent component controller has access to the functionality found in the child component’s interface controller.

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.

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.

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.