Show TOC Start of Content Area

This graphic is explained in the accompanying text Controller Interface Concept  Locate the document in its SAP Library structure

 

Introduction

The Web Dynpro controller concept which is realized within a component consequently adheres to the separation of concern design principle. This means that the full logic and computation of a Web Dynpro controller is distributed among several classes:

      Self-implemented controller classes: implement custom code. User code areas contain the self-implemented controller logic.

       Application logic is implemented within component and custom controllers having no visual interface.

       Presentation logic is implemented within view and window controllers having a visual interface.

      Internal controller classes: act as mediator classes between the Web Dynpro Java Runtime and the controller classes implementing custom code delegate additional functions like firing events, managing navigation or messages to the Web Dynpro Java Runtime. Its implementation gets automatically adapted to the related controller declarations like public methods, event subscriptions, events or the definition of view layouts.

      Generic controller classes: The Web Dynpro Java Runtime implements several generic controller APIs like IWDController, IWDComponent, IWDViewController and IWDWindowController. The generic controller APIs are required to access controller metadata (IWD…Info-APIs) or to  modify controllers at runtime (e.g. dynamic event subscription). Furthermore they are needed to access some generic service-APIs like IWDMessageManager, IWDWindowManager or IWDTextAccessor in your controller code.

 

To implement custom code in a Web Dynpro controller class an application developer must often access externally implemented controller classes providing additional services. These services are exposed to the self-implemented controller class as different types of fully generated interfaces called Web Dynpro controller interfaces.

This graphic is explained in the accompanying text Sample Scenario - Utilizing Controller Interfaces

 

The following diagram illustrates the roles of different Web Dynpro controller interfaces which are used to access externally implemented controller code. The related technical principles will successively be explained within the next sections.

This graphic is explained in the accompanying text

The application developer implements code within the Component controller and the Custom controller classes. He now wants to access externally implemented custom controller code within the component controller.

      IPrivate-API: This interface exposes logic of the internal controller class to the self-implemented controller class. It can be accessed with the private member variable wdThis of type IPrivate in every Web Dynpro controller (1). The component controller can only use the IPrivate-API of its own internal controller class. It is not visible outside.

      IPublic-API: The IPublic-interface exposes logic of the custom controller class to other controllers in the same component. To use this public controller interface within the component controller a usage relation to the custom controller must be defined first. Afterwards the IPrivate-API of the component controller gets extended with a new method wdGet<custom controller name>Controller() returning the IPublic-API of the custom controller class. It can then be accessed with wdThis.wdGet< custom controller name >Controller() (2).

      Generic Controller API: To access the generic controller interface IWDComponent within the component controller clase the shortcut variable wdComponent = wdThis.wdGetAPI() can be used (3).

This graphic is explained in the accompanying text

* The names IPrivate - and IPublic-API are the general terms for all generated controller interfaces with the prefixes IPrivate and IPublic. The qualified names of these interfaces are IPrivate<controller name>.

Here you can see how the internal controller class acts a mediator between the self-implemented controller class and the Web Dynpro Java Runtime.  The controller class sends messages to the internal controller mediator class when needed and the mediator passes them on to other Web Dynpro controller classes or to the Web Dynpro Java Runtime itself that need to be informed.

 

End of Content Area