Controllers Having A Visual
Interface
All controllers that have a visual interface are responsible for interaction with the user. This covers all aspects of data presentation, and calling action handlers in response to user input.
The highlighted areas in the figure below show the controllers and elements in a Web Dynpro component that have a visual interface. These areas span both the Visual Entities and Programmatic Entities sides of the diagram.
Having view controllers defined in the manner, Web Dynpro programs are able not only to separate business logic (contained in the component and non-view controllers) from presentation logic (contained in view controllers), but a further level of abstraction can be implemented by separating the coding that manipulates the presentation data (the view controller) from the UI elements used to display the data (the view layout).
The split between the view controller and the view layout has been shown only to highlight this specific feature of a Web Dynpro component. In reality, there is a one-to-one relationship between a view controller and its corresponding view layout, and the two are inseparable.
Structure of View Controllers
All controllers that have a visual interface conform to the following structure:
Usage Declaration of Required Controllers
In order to gain access to the data and functionality found in other Web Dynpro coding entities, usage declarations must be made. These declarations are represented by the three boxes down the left of the figure above:
● Other non-visual controllers within component
As per the Required Controllers for a non-visual controller, a view controller may declare the use of another non-visual controller within the same component in order to gain access to its data and functionality.
A controller is not permitted to declare the use of another view controller as a required controller, since this would violate the principle that view controllers are only consumers of data, not generators.
· Component usage
As per non-visual 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 processing related only to data presentation, such interaction is technically possible.
· Model usage
Although it is technically possible, it is considered very poor Web Dynpro 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 have failed to implement the principles of Web Dynpro component design correctly.
There is one legitimate exception to this rule: In Web Dynpro for Java, a certain type of popup help selector can be written called an Object Value Selector. In this situation, it is permissible for a view controller to interact directly with a model object, and thus generate its own data.
Similarities between Non-Visual Controllers and View Controllers
The following parts of the structure are identical within non-visual controllers and view controllers:
● implementation of hook methods and of other methods
● data storage area (context)
More information: Controllers Having No Visual Interface
Specific Implementations in View Controllers
The following types of implementation you write in view controllers only:
· Actions
Actions are a view controller specific mechanism for responding to events raised on the client device as a result of user interaction.
It is not appropriate (or even possible) to expect a view controller action to respond to a server side event.
· 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.
Layout
The arrangement of User Interface (UI) elements used to present information on the client device is known as the view layout. There is a one-to-one relationship between the view controller and its corresponding layout. It is not permitted for one view controller to supply data to multiple view layouts, neither is it permitted for one view layout to obtain data from multiple view controllers.
If you refer back to the section on SAP’s implementation of the Model View Controller (MVC) paradigm, it should be apparent now that UI elements act primarily as consumers of data from their corresponding view controller. However, certain UI elements (such as InputFields and DropDownLists) can also act as data generators (i.e. the user enters data through these UI elements that is then supplied to the view controller coding). Here, we see an implementation of the principle of separating data generators from data consumers – and allowing for that fact that two way data flow is also required.
More information
● Navigation Plugs and Navigation Links