Post-Submit Validation Sequence

Validators are the only accepted locations for post-submit validation logic Unlike pre-validation, there is no interaction with the solution groups, role-based UI service, or filters for post-submit validation. Therefore, the sequence for post-submit validation is much simpler than for pre-validation. In fact, it is nearly identical to the sequence for post-select validation.

First, the client infrastructure calls the validation service, passing the id associated with the “Next” or “OK” wizard action (this id is represented by a validation key). Along with the validation key, the client infrastructure passes the context data in the form of a validation criteria instance.

Key

1. The Client Infrastructure calls the validation service, passing an id associated with a wizard's "Next" or "OK" action (represented by a validation key), and the context data (represented by a validation criteria instance).

After receiving a post-submit validation request from the client infrastructure, the validation service checks to see if there is a validator associated with the wizard’s “Next” or “OK” action.

As is the case with pre-validation and post-select validation, a validator is associated with a wizard’s “Next” or “OK” action by creating an entry in a service.properties.xconf file that links the action id to the class name of the validator class for that action.

If there is not a validator registered for the action, the user is permitted to move to the next step or submit the entire wizard. Otherwise, if there is a validator associated with the “Next” or “OK” action, the validation service calls that validator to get a validation status for the action.

Key

1. The Client Infrastructure calls the validation service, passing an id associated with a wizard's next or OK action (represented by a validation key), and the context data (represented by a validation criteria instance).

2. The validation service checks to see if there is a validator associated with the "Next" or "OK" action. If so, it calls the validator to get the validation status (permitted or denied) for the action.

After the validator returns its validation result, the validation service simply passes along the validation result returned by the validator to the client infrastructure. The client infrastructure will check to see whether that status is “permitted” or “denied”. If the status is “permitted”, the user is allowed to proceed to the next step in the wizard, or complete the wizard submission. If the status is “denied”, the user restricted from moving to the next wizard step or submitting the wizard, and if the validator returned a message indicating why the action was denied, that message is displayed to the user.

Key

1. The Client Infrastructure calls the validation service, passing an action (represented by a validation key) corresponding to the page being rendered, and the context data (represented by a validation criteria instance).

3. The validation service passes the validation status (wrapped in a validation result) from the validator to the client infrastructure, which either allows the user to proceed to the next step in the wizard or submit the entire wizard, or brings the user back to the wizard step where the action was invoked.