The following process describes how a flow processor handles a
flow through states according to the definitions until the process
reaches a final state:
- 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.
- 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.
- The processor externalizer implements an object cache to significantly
improve performance.
- 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.
- 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.
- 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.
- 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.