| Contents | Overview | Examples | Editor | Forum |
|---|
Transitions between states are triggered by events and conditionalized via guard conditions. They may contain executable content, which is executed when the transition is taken.
A space-separated list of event descriptors. Like an event name, an event descriptor is a series of alphanumeric characters (optionally segmented into tokens by the "." character)
If condition is also not specified, transition will be executed immediately.
<scxml name="Scxml" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="State1">
<transition target="State2"/>
</state>
<state id="State2"/>
</scxml>
A transition matches an event if at least one of its event descriptors matches the event's name.
<scxml name="Scxml" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="State1">
<transition event="Step" target="State2"/>
</state>
<state id="State2"/>
</scxml>
An event descriptor matches an event name if its string of tokens is an exact match or a prefix of the set of tokens in the event's name. In all cases, the token matching is case sensitive.
In this example, a transition will match event names "Step", "Step.Next", "Step.Next.Completed", etc. but would not match events named "Steps.My.Custom", "StepHandler.mistake", etc.
The guard condition for this transition. Any boolean expression.
<scxml datamodel="lua" name="Scxml" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="Off">
<transition cond="_event.data==1" event="Choice" target="Select1"/>
<transition cond="_event.data==2" event="Choice" target="Select2"/>
</state>
<state id="Selection">
<transition cond="_event.data==0" event="Choice" target="Off"/>
<state id="Select1"/>
<state id="Select2"/>
</state>
</scxml>The identifier(s) of the state or parallel region to transition to.
<state id="S1">
<transition event="e">
<state id="S" initial="S1">
<state id="S1">
<onentry>
<log expr="entering S1"/>
</onentry>
<onexit>
<log expr="leaving S1"/>
</onexit>
<transition event="e" target="S1">
<log expr="'executing transition'"/>
</transition>
</state>
</state>If target of transition is its source state it is also called 'Self-transition' but is executed externally
<state id="S1">
<transition event="e" target="S1"/>
<state id="S" initial="S1">
<state id="S1">
<onentry>
<log expr="entering S1"/>
</onentry>
<onexit>
<log expr="leaving S1"/>
</onexit>
<transition event="e" target="S1">
<log expr="'executing transition'"/>
</transition>
</state>
</state>Determines whether the source state is exited in transitions whose target state is a descendant of the source state
<transition event="e" target="s11">
Source code
<scxml name="ScxmlTransitionsBehaviour" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="S" initial="s1">
<state id="s1" initial="s11">
<onentry>
<log expr="entering S1"/>
</onentry>
<onexit>
<log expr="'leaving s1'"/>
</onexit>
<transition event="e" target="s11">
<log expr="'executing transition'"/>
</transition>
<state id="s11">
<onentry>
<log expr="entering s11"/>
</onentry>
<onexit>
<log expr="'leaving s11'"/>
</onexit>
</state>
</state>
</state>
</scxml>The behavior of transitions with 'type' of internal is identical, except in the case of a transition whose source state is a compound state and whose target(s) is a descendant of the source. In such a case, an internal transition will not exit and re-enter its source state, while an external one will, as shown in the example below.
<transition event="e" target="s11" type="internal">
Source code
<scxml name="ScxmlTransitionsBehaviour" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="S" initial="s1">
<state id="s1" initial="s11">
<onentry>
<log expr="entering S1"/>
</onentry>
<onexit>
<log expr="'leaving s1'"/>
</onexit>
<transition event="e" target="s11" type="internal">
<log expr="'executing transition'"/>
</transition>
<state id="s11">
<onentry>
<log expr="entering s11"/>
</onentry>
<onexit>
<log expr="'leaving s11'"/>
</onexit>
</state>
</state>
</state>
</scxml>
Source code
<?xml version="1.0" encoding="UTF-8"?>
<scxml datamodel="ecmascript" name="ScxmlTransitionSequence" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<datamodel>
<data expr="0" id="VarTest"/>
</datamodel>
<state id="ready">
<transition event="setCustom" target="ready">
<assign expr="1" location="VarTest"/>
</transition>
<transition event="setDefault" target="ready">
<assign expr="0" location="VarTest"/>
</transition>
<state id="check">
<transition cond="VarTest == 1" target="stateCustom"/>
<transition target="stateDefault"/>
</state>
<state id="stateCustom"/>
<state id="stateDefault"/>
</state>
</scxml>Execution of transition in a compound state
When a transition is taken in a compound state, the state machine will exit all active states that are proper descendants of the LCCA, starting with the innermost one(s) and working up to the immediate descendant(s) of the LCCA. (A 'proper descendant' of a state is a child, or a child of a child, or a child of a child of a child, etc.) Then the state machine enters the target state(s), plus any states that are between it and the LCCA, starting with the outermost one (i.e., the immediate descendant of the LCCA) and working down to the target state(s). As states are exited, their <onexit> handlers are executed. Then the executable content in the transition is executed, followed by the <onentry> handlers of the states that are entered. If the target state(s) of the transition is not atomic, the state machine will enter their default initial states recursively until it reaches an atomic state(s).
In the example below, assume that state s11 is active when event 'e' occurs. The source of the transition is state s1, its target is state s21, and the LCCA is state S. When the transition is taken, first state S11 is exited, then state s1, then state s2 is entered, then state s21. Note that the LCCA S is neither entered nor exited.
Source code
<scxml name="ScxmlExecuteTransitions" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="S" initial="s1">
<onentry>
<log expr="'entering S'"/>
</onentry>
<onexit>
<log expr="'leaving S'"/>
</onexit>
<state id="s1" initial="s11">
<onexit>
<log expr="'leaving s1'"/>
</onexit>
<transition event="e" target="s21">
<log expr="'executing transition'"/>
</transition>
<state id="s11">
<onexit>
<log expr="'leaving s11'"/>
</onexit>
</state>
</state>
<state id="s2" initial="s21">
<onentry>
<log expr="'entering s2'"/>
</onentry>
<state id="s21">
<onentry>
<log expr="'entering s21'"/>
</onentry>
</state>
</state>
</state>
</scxml>LCCA (The Least Common Compound Ancestor) is the <state> or <scxml> element S such that S is a proper ancestor of all states on stateList and no descendant of S has this property. Note that there is guaranteed to be such an element since the <scxml> wrapper element is a common ancestor of all states. Note also that since we are speaking of proper ancestor (parent or parent of a parent, etc.) the LCCA is never a member of stateList.
NOTE: Parallel states can not be LCCA
 |
|---|
When External event occurs, we will leave StateShape3, StateShape4 and ParallelShape2 until LCCA StateShape1 is found |
To execute a microstep, the SCXML Processor MUST execute the transitions in the corresponding optimal enabled transition set, where the optimal transition set enabled by event E in state configuration C is the largest set of transitions such that:
c) there is no optimally enabled transition outside the set that has a higher priority than some member of the set.
To execute a set of transitions, the SCXML Processor MUST first exit all the states in the transitions' exit set in exit order.
the SCXML Processor executing a set of transitions MUST then [after the onexits] execute the executable content contained in the transitions in document order.
the SCXML Processor executing a set of transitions MUST then [after the exits and the transitions] enter the states in the transitions' entry set in entry order.
| TOP | Contents | Overview | Examples | Editor | Forum |
|---|