HTML flow processor

The toolkit provides an implementation of a specialized Automaton for supporting HTML client requests on the server. The specialized Automaton is a state machine that can handle multiple execution hits and reply to each hit according to a defined flow. It provides a flow processor (DSEHtmlProcessor) that controls navigation within the client by performing different actions depending what the user selects in a dialog. The navigation process represents each dialog as a state in the navigation process.

The DSEHtmlProcessor extends the DSEProcessor class and adds the following functionality to the generic flow processor:

▪ The HTML flow processor can be asynchronous in that it can delegate the responsibility of the flow outside the state machine. That is, the HTML flow processor can release control of the flow before it finishes. The toolkit stores the state of the processor so that it can re-establish the processor later. The generic flow processor is only synchronous.

▪ The HTML flow processor has two special kinds of state: page and subFlow. These states determine how the HTML flow processor handles events. When the processor reaches one of them, it releases control of the flow. The DSEHtmlProcessorOperation assumes control of the flow at that point. When the processor achieves one of these states, the only event that causes it to resume the flow is an external event.

When the HTML flow processor is in the page state, it resumes control of the flow when it receives an event from an HTML page containing a field in which the user has done something. The value for the field determines the name of the event (dse_nextEventName) raised by the page.

When the HTML flow processor is in the subFlow state, it raises a subflow running in a child processor. The processor resumes control of the flow when it receives an event from the child processor. The name of the event is the value of the typeIdInfo attribute of the final state of the child processor.

During a flow, the HTML flow processor enters the page and subflow states twice. The first time occurs before the processor releases control and the second time occurs when it resumes control. During the first state entry, the toolkit executes the entry actions without triggering the event listeners. During the second state change, the toolkit processes the event normally. Once the processor loses control, the toolkit stores relevant processor information such as the processor's context and then deletes the processor instance from memory. When it is time for the processor to regain control, the toolkit recovers the processor instance using the stored information. Before the toolkit stores the processor context, the toolkit unchains it from its parent, which is the session context. This means that the HTML flow processor's context must not have a defined parent.

▪ The HTML Channel uses the HTML Processor Manager to manage the instances of processors if the processors cache is enabled. In the cache, the HTML Processor Manager stores the processor instances. This feature is particularly useful for HTML flow processors because the toolkit frequently unloads and re-instantiates them when they reach one of their special states.