Purpose
This section provides information on the data transport during the request processing.
The first request is not described as it only involves the reading of the metadata and the initial display of the user interface.
At certain points of the phase model, application developers can influence the user interface layout themselves by programming dynamically.
Process Flow
The following graphic schematically shows the process flow during data transport:
The process flow of event handling is shown in detail in the following graphic:
Data Transport from Client to Data Container
Data – for example, user input – is transported from the client to the data container. The data container is used for temporary data storage. At this point, data in the data container is only available to the runtime environment, but not to the application developer.
Validation of the User Input
All user entries are checked. The detection of an entry with errors, however, does not terminate the check. The transport of the remaining data is not stopped. Any data with errors is not transported to the context.
The following checks/conversions are performed:
● Type-specific checks (for example, no letters in date fields)
● User-specific conversions (for example, date format according to user settings).
● Data Dictionary checks/conversions
○ Uppercase conversion
○ Conversion exits
○ It is taken into account when a context node with Data Dictionary reference to a currency field also contains the reference field.
● Check against the value set of the attribute
An error message is created for each input with errors and is displayed after the data transfer to the controller context.
Data Transport from the Data Container to the Context
The data is now available for application programs.
WDDOAFTERACTION
This method is called for all visible views at the time an action is executed. Here functions can be placed that are carried out equally for all associated event handlers. This avoids any unnecessary multiple programming in the event handlers.
WDDOBEFOREACTION
Before an action is triggered, you can perform your own validations using this method. The method can only be used for view controllers. It is used for all visible views of the component assigned to the current phase model instance. These include all embedded components.
Handling of Actions and Events
This step is performed independently from the data transport between data container and context. When an input with errors is found during the validation of the user input, a corresponding error message is displayed and the application developer can correct the data.
In general, there are two different types of event handlers (see detailed graphic of the event handling):
● Standard event handlers are only called if no errors were found in the user input during the validation. If errors were found, an event handler of this type is skipped without processing and the runtime continues with the next step.
● Validation-independent event handlers are always called even if errors are found during validation. In this case, the corresponding error messages created during validation are nevertheless displayed.
Navigation is only possible when it is triggered by an event handler – that is, an event handler is called to trigger navigation.
WDDOBEFORENAVIGATION
In this process phase, the method WDDOBEFORENAVIGATION can be used to perform an additional validation of those controller contexts that are required in the application but have not been validated in the request/response cycle yet. This is important for more complex Web Dynpro applications in particular. This method can only be used for the component controller. The method is used for the component assigned to the phase model instance and all embedded components.
Navigation can be interrupted at this point if an error occurred during the event handling in the previous step. The method CANCEL_NAVIGATIION can be called in the interface IF_WD_COMPONENT to terminate navigation. This method call prevents navigation for the entire application within a request/response cycle. Navigation requests are deleted during the subsequent run of the phase model and must be reinitialized.
Navigation and Initialization of the Subsequent View
A navigation triggered by a corresponding event is now executed. The inbound plug of the subsequent view is called and the corresponding event handler is processed.
View Modification
Once the method WDDOINIT of the corresponding view is executed by the runtime and the view is created accordingly, the application developer can modify the UI tree of a view, for example, by dynamically adding view elements.
The method WDDOMODIFYVIEW is used for all visible views of the component associated to this phase model instance and the embedded components.
WDDOPOSTPROCESSING
This method is called in the last process step before rendering. Therefore, it allows you to add application-specific clean-up processes.
Rendering
During rendering, the user interface is displayed on the screen – that is, the structure of the UI tree and the filling of elements from the context.
Due to the rendering, the entire data of the views to be displayed is retrieved. The corresponding context may only be filled at the time of rendering. This also requires the calling of the corresponding supply functions. The application developer should make sure that no exceptions are raised in supply functions.
Dialog Box
When opening a modal a popup with Web Dynpro content), an additional phase model instance is automatically created. This internal popup is opened asynchronously after the last phase of the phase model instance of the currently active window. After the last phase of the phase model instance of the popup, this internal popup is also closed asynchronously. Finally, the phase model of the now active window is run one more time.
No comments:
Post a Comment