To create the transition context, the JSP code passes the name of the transition and an array of data names obtained from the submitted form to the JspContextServices class. An API of JspContextServices enables you to modify the transition context by adding or removing these data elements. If the transition context already exists, the JspContextServices class cleans it by removing all references to data elements and then adds new data element references.
The JspContextServices does not actually create or update the transition context at the moment it is invoked. Instead, it stores the set of data names to be created, added, or removed for the specified transition context within the HtmlStateInfo object for the current state. When the associated transition request hits the server, the infrastructure uses the stored information to create and/or update the transition context. For the data names available in the state information, the infrastructure searches for each DataElement in the context hierarchy. It then clones the DataElement using the standard protocol and creates complex data structures (keyed collections and indexed collections) to hold the data. For this purpose, the HtmlStateInfo class has an attribute named transitionContexts. This attribute is a Hashtable whose key is a concatenation of the current state name and the transition name and whose value contains an instance of an object named TCInfo.
The transition context remains available in the state definition so that the toolkit is able to save it when the server finishes the request and restore it when the user clicks the button and the request goes to the server again. The transition context may be located on a different node according to the load-balancing definitions for the solution.
The transition context maintains a list of all data elements that it receives from a form. However, there may be some data elements that do not require validation. For example, there may be fields in the page not associated with the submit button and the user expects not to lose the information contained within them when he or she submits the request. While the transition context maintains the data elements for these fields so that the client can redisplay their value, the toolkit should not validate their value as part of the submit button action. To support this functionality, the application sets the dse_ignoreValidationResults attribute of these data elements to true. For each data element that the toolkit does not validate, when the toolkit updates the process context with the contents of the transition context, it resets the ErrorInfo object and stores the input data in the data element's dse_inputObject parameter. The replay JSP code can use this parameter when rendering the DataElement back to the client.
The transition context mechanism provides a way to allow the process flow to assess the validation results. The application logic can then make a decision based on the contents of the context hierarchy. For example, there is a page that contains an entry field, an OK button, and a cancel button. If the user types the wrong value in the field and clicks the cancel button, a confirmation page in which the user can cancel the cancellation appears although the field validation fails. The transition context still validates the input data, but because there is a confirmation page, the transition context allows the process logic to determine what happens if the data is not valid.
The confirmation page presents the user with a Yes button for accepting the cancellation and a No button for resuming the navigation with the initial form. If the user clicks the Yes button, the definition for the process navigation flow determines which page the browser displays next without caring about the contents of the field. If the user clicks the No button, the definition for the process navigation flow determines that the entry page is re-presented. The field entered in the initial form was validated and the page warns the user of the invalid value so that the user may amend it and resume the navigation.
To support this functionality, transitions have a delegateValAssessment attribute. When the value for this attribute is true and the request associated with this transition reaches the server, the processor maintains the transition context in the request scope by chaining it to the process context and assigning it the role of process context. The flow continues regardless of the results of the data validation. The process logic may evaluate the results of the data validation and behave according to application rules. When the flow moves to the next state page, the JSP code for the reply page can access the data of the previous input form to render whatever information the client requires. The reply page JSP (typically a confirmation page) accesses the transition context (it is the first context in the hierarchy) to create a page that displays the same entry fields as the previous form or include the data as hidden fields to ensure that the server receives these fields when the client submits the next request. If you need a specialized confirmation page that displays the same fields as the original form, you need to create a concrete JSP per confirmation. Otherwise, you could use a generic confirmation page that includes a question, an OK button, and a cancel button. In addition, a protocol in the JspContextServices automatically adds fields into the transition context for the "quit cancel" transition. Once the JSP builds the reply page contents, the processor discards the transition context and restores the process context.