Constituent Parts of a Component
As shown in the figure in section Components, a component consists of the following elements:
Component Controller
The component controller is the master controller for a Web Dynpro component. As soon as you declare the existence of a Web Dynpro component, the component controller is automatically created. You cannot have a Web Dynpro component without a corresponding component controller.
The component controller can be thought of as being hierarchically superior to all other controllers in the component. Consequently, the lifespan of the component is always equal to the lifespan of the component controller.
When the Web Dynpro framework receives a URL that corresponds to a Web Dynpro application, the component controller of the root component is instantiated. Here is an example of where the Web Dynpro framework automatically interacts with coding written by the Web Dynpro developer.
Since the component controller has no visual interface, it is incapable of directly presenting any information to the user. This task, however, is of no concern to the component controller. The component controller should contain only the coding necessary to control the interaction with:
● All other controllers
● Child component instances
● Model objects
You should regard the component controller as the central point of control for the behavior of the Web Dynpro component.
Custom Controllers
Custom controllers are similar to the component controller in that they also 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.
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 controlled by:
■ 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
Interface Controller
It has already been stated that one Web Dynpro component may declare the use of another Web Dynpro component to form a parent-child usage relationship. In such cases, the only point of interaction between the parent and child components is the functionality found in the child’s interface controller.
Referring back to the figure in section Components, there is a usage declaration arrow pointing from the component controller to a child component. Notice that the arrow joins the child component at the top right-hand corner. This is the location of the child’s interface controller.
At no time does the Web Dynpro framework interact with a component’s interface controller. It is only ever used when a Parent-Child relationship exists between two Web Dynpro components. Therefore the methods declared in an interface controller will only ever be called by coding written by the application developer.
View Controller
A view controller is the controller within a Web Dynpro component that handles both the presentation of business data, and processing of responses to user input. A view controller is not responsible for the generation of business data.
According to the fundamental principles of Model View Controller (MVC) design, there is a strict division of labour between those parts of the program that generate data, and those parts that consume data. With respect to the other controllers in a component, a view controller is always considered to be a consumer of data; therefore it can never be nominated as a Required Controller by any other Web Dynpro controller.
View Layout
A view layout holds the description of the appearance and behavior of a rectangular area of the user interface. This description is typically defined at design time, and developers need not concern themselves with the specific technology implemented by the client device. This greatly simplifies the Web Dynpro developer’s job because they no longer need to spend those many tedious hours trying to make some graphical widget work in three different browser versions.
The positioning of UI elements within a Web Dynpro view layout is typically performed using design time declarations. No consideration need be given as to whether the client understands a certain version of JavaScript, or whether a certain HTML tag is supported. The Web Dynpro framework automatically handles all these considerations for you at runtime.
In respect of the view layout, the only thing the Web Dynpro developer needs to be concerned about is the amount of screen space available on the client device. A hand-held device will have only a small screen area available, whereas a browser running on a desktop computer will have a much larger screen area available. This will affect the quantity of information you can present to the user in one screen, but from a Web Dynpro programming perspective, it has no bearing whatsoever on the application coding.
All view layouts need UI elements in order for information to be made visible on the screen. UI elements are abstract representations of graphical elements found across the range of client devices supported by Web Dynpro.
When you declare that a certain UI element will be used on the screen, you are not writing any actual HTML or JavaScript: the reason being that the view layout is client independent – and it is not until runtime – that the Web Dynpro framework actually decides what specific encoding is required to render the screen.
Window Controller
A window controller handles the processing for an aggregation of views that are embedded in the assigned window. A Web Dynpro component may have zero, one or more window controllers.
In order for any particular view to be visible through the component’s visual interface, it must first have been embedded into a window. The window is implemented by the window controller. Thus the window controller can be seen as being hierarchically superior to the view controllers.
Navigation between a window and its embedded views is performed via the window’s inbound and outbound plugs. These window navigation plugs are part of the window controller.
More Information