State Machine and circular references

[gordonp]

Hi, first time post. Been trying to wrap my head around the state machine module.

My question involves circular references within a state machine.

Is the following state machine code valid?

:

var fsm:XML =
<fsm initial={STATE_ONE}>
<state name={STATE_ONE}
entering={ENTER_STATE_ONE}
exiting={EXIT_STATE_ONE}
changed={CHANGED_STATE_ONE}>
<transition action={ACTION_MOVE_TO_STATE_TWO} target={STATE_TWO}/>
</state>

<state name={STATE_TWO}
entering={ENTER_STATE_TWO}
exiting={EXIT_STATE_TWO}
changed={CHANGED_STATE_TWO}>
<transition action={ACTION_MOVE_TO_STATE_ONE} target={STATE_ONE}/>
<transition action={ACTION_MOVE_TO_STATE_TWO} target={STATE_TWO}/>
<transition action={ACTION_MOVE_TO_STATE_THREE} target={STATE_THREE}/>
</state>

<state name={STATE_THREE}
entering={ENTER_STATE_THREE}
exiting={EXIT_STATE_THREE}
changed={CHANGED_STATE_THREE}>
<transition action={ACTION_MOVE_TO_STATE_TWO} target={STATE_TWO}/>
</state>

</fsm>;

The key point being that any state can transition to STATE_TWO, even when you are in State two. I have duplicated the transition action to STATE_TWO across all three states. The idea here as that you can go into STATE_TWO from anywhere, but certain trajectories require STATE_TWO. For example, if I understand this correctly the above state machine would prohibit a direct jump from STATE_ONE to STATE_THREE, without first passing through STATE_TWO.

The context here is something like a modal view in my application. Imagine STATE_TWO being a modal dialog of some sort that can be transitioned in and out of, from anywhere in the application.

Is there any problems with my logic here? Does duplicating action ACTION_MOVE_TO_STATE_TWO introduce any ambiguities or unanticipated gotchas?

Would it be better to not duplicate the actions at all?

For example would the following code be better from a best practices point of view?

:

var fsm:XML =
<fsm initial={STATE_ONE}>
<state name={STATE_ONE}
entering={ENTER_STATE_ONE}
exiting={EXIT_STATE_ONE}
changed={CHANGED_STATE_ONE}>
<transition action={ACTION_MOVE_TO_STATE_TWO_FROM_ONE} target={STATE_TWO}/>
</state>

<state name={STATE_TWO}
entering={ENTER_STATE_TWO}
exiting={EXIT_STATE_TWO}
changed={CHANGED_STATE_TWO}>
<transition action={ACTION_MOVE_TO_STATE_ONE_FROM_TWO} target={STATE_ONE}/>
<transition action={ACTION_MOVE_TO_STATE_TWO_FROM_TWO} target={STATE_TWO}/>
<transition action={ACTION_MOVE_TO_STATE_THREE_FROM_TWO} target={STATE_THREE}/>
</state>

<state name={STATE_THREE}
entering={ENTER_STATE_THREE}
exiting={EXIT_STATE_THREE}
changed={CHANGED_STATE_THREE}>
<transition action={ACTION_MOVE_TO_STATE_TWO_FROM_THREE} target={STATE_TWO}/>
</state>

</fsm>;

Note that now there is no duplication of the transition actions. In someways the the first variation seems simpler, because I can have a small listing of transitions that are redundant but clear meaning of intention.

ACTION_MOVE_TO_STATE_TWO

always means what it says no matter what state I am in.

In the latter state machine I would have to determine ahead of time in my code and pick from three possible transitions

ACTION_MOVE_TO_STATE_TWO_FROM_ONE
ACTION_MOVE_TO_STATE_TWO_FROM_TWO
ACTION_MOVE_TO_STATE_TWO_FROM_THREE

depending on what state I was in.

Hopefully my question is clear. Any thoughts, or guidance?

By the way, thanks Cliff for all the work you have put into pureMVC. It has been a useful tool.

[puremvc]

There is no problem with the first way that you defined it. The second way is not good because it means the sender of the action has to be aware of the state in order to know what action to send.

-=Cliff>

[gordonp]

Thanks Cliff. That makes sense.

One followup question. In the case of being in STATE_TWO and the action

:

<transition action={ACTION_MOVE_TO_STATE_TWO} target={STATE_TWO}/>
e.g. this code block

:

<state name={STATE_TWO}
entering={ENTER_STATE_TWO}
exiting={EXIT_STATE_TWO}
changed={CHANGED_STATE_TWO}>
<transition action={ACTION_MOVE_TO_STATE_ONE} target={STATE_ONE}/>
<transition action={ACTION_MOVE_TO_STATE_TWO} target={STATE_TWO}/>
<transition action={ACTION_MOVE_TO_STATE_THREE} target={STATE_THREE}/>
</state>

Does this behave differently in any way in terms of Entry and Exit guard notifications? Technically I would presume you are exiting and then entering right back again into the same state. So technically the STATE_TWO changed event would occur which, while technically behaves like a real notification, semantically no state has changed. But briefly there is a moment where you would be out of the state and right back in.

Is my thinking correct here? Are there any odd side effects to having it setup this way? If the state transition is cancelled, does that have any unexpected implications in this scenario?

The reason I wanted to add the transition in STATE_TWO , is so that certain actions could always be called regardless of state. And so I would know that ACTION_MOVE_TO_STATE_TWO would always work no matter what state I was in.
 

[puremvc]

A reentrant State's transition to itself is the same as any other State transition. The enter and exit guards are called followed by the state-specific 'changed' announcment and then StateMachine.CHANGED.

Suppose you have a Gallery State where you view the artwork of various artists. Say you're browsing the works of Van Gogh. Then you click a button to view Salvador Dali. The Gallery state reenters itself with the new artist ID passed as data in the StateMachine.ACTION note body. In the Gallery state changed announcement, you request the Dali artwork from the ArtProxy, and when it returns, you redisplay the Gallery with the new artists works.

-=Cliff>