The following process describes how a flow processor handles a flow through states according to the definitions until the process reaches a final state:
1 The processor externalizer instantiates a given instance of the processor from its external definition. The behavior of the processor externalizer is the same as other externalizers in the toolkit to create an object.
▪ The externalizer searches for the name of the flow processor.
▪ It obtains the flow processor's class from the configuration file.
▪ It sends the initializeFrom(Tag aTag) method to the flow processor instance to initialize it according to the definitions embedded in the tag.
2 When the toolkit initializes an instance of a flow processor, it caches in memory all of the possible states along with their actions, transitions, and data without actually instantiating them. Objects from these definitions are only created at runtime when they are required during the life cycle of the process.
3 The processor externalizer implements an object cache to significantly improve performance.
4 The toolkit executes the processor instance. The process handled by the flow processor starts in its initial state and follows a defined path until it enters one of its final states.
5 When the processor enters a state, the state registers with notifiers as being interested in any events specified in the state's transitions. The notifiers can be any notifier available in the context or any of the actions being executed.
6 The processor synchronously executes the state's entry actions in the order in which they appear in the external definition of the state. If an entry action causes an event to fire and the event belongs to a transition defined for the state, the processor places the event in an internal queue to synchronize the actual handling of events.
7 After executing the entry actions, the flow processor checks the event queue and executes any events it finds there. If there are no events in the queue, the processor waits in the state for a triggering event. The use of the event queue to synchronize events does not prevent actions and guard conditions from having the opportunity to handle an event fired by a notifier while the processor is executing entry actions. The processor provides the event to them without losing the original event data.
To execute an event, the flow processor executes the actions for the event's transition after evaluating the guard conditions for each action. Depending on the results of evaluating the guard conditions and applying flow modifiers, the flow processor performs the exit actions defined for the state and then enters the defined target state to advance the process.
The following diagram and description describes the interaction of the various entities of the Automaton in a flow processor that defines the flow of views in a Java application:
The processor enters the Start state. It displays view1 as its entry action. The view contains an OK button and a Cancel button. The processor waits in the Start state until the use clicks a button. This creates an NC.OK or NC.Cancel event depending on which button the user clicked. The processor has registered with the notifiers for both events so that it can handle them. If the event is NC.OK, the processor performs the action. In this case, the action is a transition to the View2 state. If the event is NC.Cancel, the processor transitions to the Error state.
