Phase Model 

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 a 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. If the data type is compatible, even data with errors is 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.

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 not 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.

 

Popups

An instance of the phase model exists for each active window. This means that each phase model instance is assigned to exactly one window and one component.

When opening an internal popup (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.