A transitionable state that executes one or more actions when entered. When
the action(s) are executed, this state responds to their result(s) to decide
what state to transition to next.
If more than one action is configured, they are executed in an ordered chain
until one returns a result event that matches a valid state transition out of
this state. This is a form of the Chain of Responsibility (CoR) pattern.
The result of an action's execution is typically treated as the contributing
criteria for a state transition. In addition, any state accessible via the
RequestContext may be tested as part of custom transitional
criteria, allowing for sophisticated transition expressions that reason on
contextual state.
Each action executed by this action state may be provisioned with a set of
arbitrary execution properties. These properties are made available to the
action at execution time and may be used to influence action execution
behavior.
Common action execution properties include:
Property
Description
name
The 'name' property is used as a qualifier for an action's result event,
and is typically used to allow the flow to respond to a specific action's
outcome within a larger action execution chain. For example, if an action
named myAction returns a success result, a
transition that matches on event myAction.success will be
searched, and if found, executed. If this action is not assigned a name, a
transition for the base success event will be searched and if
found, executed.
This is useful in situations where you want to execute actions in an ordered
chain as part of one action state, and wish to transition on the result of
the last one in the chain. For example:
When the 'setupForm' state above is entered, the 'setup' action will execute,
followed by the 'referenceData' action. After 'referenceData' execution, the
flow will then respond to the 'referenceData.success' event by transitioning
to the 'displayForm' state.
method
The 'method' property is the name of a specific method on a
MultiAction to
execute. In the MultiAction scenario the named method must have the signature
public Event ${method}(RequestContext). As an example of this
scenario, a method property with value setupForm would bind to
a method on a MultiAction instance with the signature:
public Event setupForm(RequestContext context).
As an alternative to a MultiAction method binding, this action state may
excute a
bean invoking action
that invokes a method on a POJO (plain old java.lang.Object). If the method
signature does accept arguments, those arguments may be specified by using
the format: methodName(${arg1}, ${parg}, ...). Argument
${expressions} are evaluated against the current RequestContext,
allowing for data stored in flow scope or request scope to be passed as
arguments to the POJO in an automatic fashion. In addition, POJO return
values may be exposed to the flow automatically. See the bean invoking action
type hierarchy for more information.
If more than one action is configured, they are executed in an ordered chain until one returns a result event that matches a valid state transition out of this state. This is a form of the Chain of Responsibility (CoR) pattern.
The result of an action's execution is typically treated as the contributing criteria for a state transition. In addition, any state accessible via the
RequestContextmay be tested as part of custom transitional criteria, allowing for sophisticated transition expressions that reason on contextual state.Each action executed by this action state may be provisioned with a set of arbitrary execution properties. These properties are made available to the action at execution time and may be used to influence action execution behavior.
Common action execution properties include:
myActionreturns asuccessresult, a transition that matches on eventmyAction.successwill be searched, and if found, executed. If this action is not assigned a name, a transition for the basesuccessevent will be searched and if found, executed.This is useful in situations where you want to execute actions in an ordered chain as part of one action state, and wish to transition on the result of the last one in the chain. For example:
<action-state id="setupForm"> <action name="setup" bean="myAction" method="setupForm"/> <action name="referenceData" bean="myAction" method="setupReferenceData"/> <transition on="referenceData.success" to="displayForm"/> </action-state>When the 'setupForm' state above is entered, the 'setup' action will execute, followed by the 'referenceData' action. After 'referenceData' execution, the flow will then respond to the 'referenceData.success' event by transitioning to the 'displayForm' state.MultiActionto execute. In the MultiAction scenario the named method must have the signaturepublic Event ${method}(RequestContext). As an example of this scenario, a method property with valuesetupFormwould bind to a method on a MultiAction instance with the signature:public Event setupForm(RequestContext context).As an alternative to a MultiAction method binding, this action state may excute a bean invoking action that invokes a method on a POJO (plain old java.lang.Object). If the method signature does accept arguments, those arguments may be specified by using the format:
methodName(${arg1}, ${parg}, ...). Argument ${expressions} are evaluated against the currentRequestContext, allowing for data stored in flow scope or request scope to be passed as arguments to the POJO in an automatic fashion. In addition, POJO return values may be exposed to the flow automatically. See the bean invoking action type hierarchy for more information.