Accessing Other Controller Functions With
IPublic Interface
The next Web Dynpro controller interface type we consider is the IPublic interface. It is exposed by every non-view Web Dynpro controller and can be invoked by all controllers in the same component. With this interface it is easily possible to share logic across several controllers so that no code redundancies occur.
Like the IPrivate interface the IPublic interface gets fully generated by the Web Dynpro Tools based on the controller declarations made by the application developer.
A simple example is the definition of a new public method executeSevice() in the component controller. This method is automatically added to the component controller’s IPublic-API so that it can be invoked within a view controller’s action event handler: wdThis.wdGetSampleCompController().executeService().
Before going into the details of the IPublic-API we first consider the controller visibility concept the different Web Dynpro controllers adhere to.
Controller Usage Relations and Visibility
In case a Web Dynpro controller A requires a function implemented in another controller B a controller usage relation must explicitly be defined first within the Web Dynpro Tools.
When defining controller usage relations the following aspects must be considered.
● By default no controller usage relations are defined: By default every Web Dynpro controller is not related with any other controller in the same component which means that no controller is visible for other controllers first. With this strategy the Web Dynpro controller model minimizes the dependencies between separate controller classes. It lies in the responsibility of the application developer to explicitly define the required controller dependencies or controller usage relations.
● View controllers cannot be used: With respect to the other controllers in a component, a view controller is always considered to be a consumer of data and a caller of logic; therefore it can never be nominated as a required or used controller by any other Web Dynpro controller. As a consequence a view controller does not expose an IPublic interface to other controllers.
● Cyclic controller usages should be avoided: The definition of a cyclic controller usage relation – like a component controller uses a window controller and vice versa – should be avoided because this may lead to an unexpected behavior at runtime.
Invoking the IPublic-API of a Used Controller
To invoke the IPublic interface exposed by a non-view controller a usage relation to this controller must be defined first (figure above, point 1).
With this controller
usage definition the IPrivate-API of the consuming controller is automatically
extended by the method
wdGet<used controller
name>Controller() which
returns the IPublic
interface of the used
controller (2).
The next diagram illustrates a typical controller scenarion in which the IPublic interfaces of non-view controllers are invoked by other controllers in the same component.
As view controllers cannot be used by other controllers they principally do expose an IPublic-API to other controllers.
IPrivate Extends IPublic
An important relationship between the two generated Web Dynpro controller interface types is, that the IPrivate extends the IPublic interface. This means, that all methods and constants the IPublic-API exposes to other controllers can be accessed within the controller class itself by invoking the IPrivate-API.
Depending on which declaration you make in a controller the IPublic or the IPrivate API is adapted correspondingly. Some definitions are exposed to other controllers within the IPublic interface, others do only affect the IPrivate interface so that they are not visible outside:
● IPublic-API: public controller methods, event handlers, event id of type IWDEventId for the dynamic event subscription in another controller.
● IPrivate-API: accessor method to invoke the IPublic-API of a used controller, accessor method to invoke the IWDComponentUsage-API for a used component, fire event methods, event handler id of type IWDEventHandlerId for the dynamic event subscription in the same controller.
Based on these rules it is clear why a declared event cannot directly be fired within another controller. As the method wdFireEvent<event name>() is added to the IPrivate- but not to the IPublic-API you must explicitly define a public method which can be invoked outside and which itself calls the fire method.
Example
