The following process describes how the transition context mechanism works:
1 Transition contexts are usually statically defined in the process definition. However, when the client submits an HTML form for processing, the JSP for the page may use a JspContextServices class (such as DSEJspContextServices) to create a transition context if one does not already exist. This feature helps to reduce the effort for defining and maintaining transition contexts.
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.
2 The HTML Channel then uses the transition context to validate the input data and store the converted data elements (using the associated typed data "html" converter to convert the input String) and/or the ErrorInfo objects that result from the validation.
3 Depending on the result of the validation and whether the transition has a delegateValAssessment attribute (see below) or it is set to false, the following occurs:
▪ If the field and cross-field validations are successful, the infrastructure promotes the objects available in the transition context into the application/processor context by simple reference. The transition context is then discarded.
▪ If validation is unsuccessful, the infrastructure leaves the transition context in the hierarchy and passes control to the JSP that it is configured by the application (in the error page attribute of the request) when errors occur. This JSP accesses the transition context to obtain its data and error information. For this purpose, the custom JSP tags can hide the usage of the JspContextServices API inside of the pages.
4 The reply page JSP accesses the Operation Context (being either the transition context containing validation errors or the process context containing the result data) to create a page that displays the information required for the response. For this purpose, the custom JSP tags can hide the usage of the JspContextServices API inside the pages.
5 Once the server has processed the JSP (either the JSP for the next state or the JSP invoked when errors occur), the processor unchains the transition context from the hierarchy and then discards it.
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.
