Data is validated every time a new HTML client request is received on the server with values to update the operation or process context. There are two types of validation: single data field validation and business function cross-field validation. In a field validation, the type's validator performs a syntactic validation to check whether the data is valid for the field. Once the toolkit has validated the data syntactically, it can then validate the data semantically. Semantic validation checks whether the data conforms to specified business rules. For example, a transfer has a due date and the due date can only be on a business day. The validator first checks (a syntax validation) that the due date field contains a valid date. If the date is valid, the cross-field validator then checks whether the due date is a business day (a semantic validation).
The typed data field definitions in the dsetype.xml file contain the required validation rules for single data field syntactic validation. The field validation process goes through the keyedCollection, finds the data element in the context with the same name as the data element in the file, validates the data element (syntactically through the data field validator and semantically through the operation cross-field validator), and, if validation is successful, updates the context. All the exceptions received for each field during validation are added to a Hashtable object kept in the errorInfo attribute of the data element. This attribute is later used by the JSP to show any error related to a field. See Performing validation.
If you are using an HTML flow processor's transition with context, the processor's context is updated only if the validation is successful (see Transition contexts).
After performing single data field validation (both syntactic and semantic), the toolkit performs a cross-field validation of the relationship between the current field's value and the value of another field. An example of a relationship validation is when an address cross-field validator checks that a zip code is valid for the state identified in another field. See Performing cross-field validation.
Although a semantic validation is a field validation, the cross-field validator is the object that performs this check. This is because semantic validation and cross-field validation require a context. The cross-field validation requires a context because it uses more than one field to validate the data. The semantic validation requires the context because the meaning of the field may vary depending on the field's status inside the context.
A transition context stores and validates input data before the processor commits valid data to the process context. To do this, a transition context retains the input data of a form along with their related data elements and any ErrorInfo objects obtained when validating the data. This provides the following benefits:
▪ Security. A transition context acts as a specification of the input from a form. The system ignores any submitted information that is not in the transition context definition. This protects the application by preventing unexpected data from being inserted into the application context.
▪ Data filtering. A transition context defines the set of data related to a specific action in a page. This provides you with the ability to filter data items held within a page.
▪ Data integrity. A transition context preserves application data integrity because the processor only copies validated data into the application context.
▪ Transient error information. The life cycle of a transition context is very short and the toolkit takes advantage of this in its management of error information. The processor attaches an ErrorInfo object to any data elements in the transition context that are in error so that JSP code can use this object. Once the processor discards the transition context, it also discards these ErrorInfo objects.
By preserving input data in a transition context, the processor is able to restore input data should a user return to a canceled page.
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.
JspContextServices interface and DSEJspContextServices class provide methods to dynamically create a transition context (see Transition contexts) for the current state of a processor or to add or remove a specific data element to or from the newly created transition context. JSPs associated with a page such as a confirmation page directly invoke these methods to ensure that the same data elements that are available for the JSP will also be available for the next one.
To do this, the DSEJspContextServices contains the following methods:
This method stores the name of the parameter to be set and its value in the transitionParameters Hashtable, which is stored in the TCInfo instance for the transitionName of the current state. This method may be used by the invoker to set special transition attributes such as delegateValAssessment.
These methods do not actually update the transition context when they are invoked. Instead, they store the information in the transitionContexts attribute within the HtmlStateInfo object for the current processor state. When the request associated with the transition hits the server, the actual transition is restored and updated with the previously gathered information.
