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(TM) 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.