Phase Model

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

  • If a context node with Data Dictionary reference to a currency field also contains the reference field, this is taken into account

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

Multiple Actions per Roundtrip

As of Enhancement Package 2, the Web Dynpro ABAP runtime allows multiple actions to be processed in a roundtrip. The following rules apply:

• For each action to be executed, the hook methods WDDOBEFOREACTION and WDDOAFTERACTION are also executed (for all visible views)

• Validation errors prevent standard actions from being executed (as before). As before, the application can record validation errors in the hook method WDDOBEFOREACTION and in doing so, prevent standard actions from being executed. One new feature is that validation errors reported in the action handlers or in hook method WDDOAFTERACTION also prevent subsequent standard actions from being executed.

• Until now, validation errors prevented navigation and the execution of the WDDOMODIFYVIEW methods. Now, navigation and the WDDOMODIFYVIEW methods can be executed if at least one action was executed. As before, the WDDOMIDIFYVIEW methods are still executed if no actions were triggered.

• The message manager is reset (all messages that are not permanent are deleted) before the first action

• If the keep_messages = abap_true parameter was set for at least one of the actions to be executed, the messages are not deleted

You can deactivate this feature by setting the value of the application parameter WDALLOWMULTIPLEACTIONS to abap_false.

Handling Actions and Events

This step is performed independently of 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 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 only takes place 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 yet been validated in the request/response cycle. 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 event handling in the previous step. To terminate navigation, the method CANCEL_NAVIGATION can be called in the IF_WD_COMPONENT interface. 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.

Dialog Boxes (Popups)

When a modal dialog box with Web Dynpro content is opened, an additional phase model instance is also generated. 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.