On 9/17/06, Jon Brule <[EMAIL PROTECTED]> wrote:
I was able to resolved the sticky points of navigation into and out
from the "task" states by using both history and a generic task event
with an associated task variable. The following is the state machine
XML:

<snip/>

Oh, and if you want to post your example / usecase or any pointers on
the wiki [1] or the website [2], I'm sure it will help others. The
wiki is open to all (after a quick signup) and website related patches
can be attached to JIRA [3].

Finally, making the current event name(s) available isn't technically
any big deal, its just that the WD doesn't require it (so using the
payload or Context data to make decisions --as below -- would be a
preferred alternative).

-Rahul

[1] http://wiki.apache.org/jakarta-commons/SCXML/HomePage
[2] http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/xdocs/
[3] http://jakarta.apache.org/commons/scxml/issue-tracking.html


<scxml xmlns="http://www.w3.org/2005/07/scxml";
       version="1.0"
       initialstate="S1">

 <state id="S1">
   <initial>
     <transition target="S1history"/>
   </initial>
   <history type="deep" id="S1history">
     <transition target="S11"/>
   </history>
   <state id="S11">
     <transition event="event" target="S12"/>
   </state>
   <state id="S12">
     <onentry>
       <log label="mode" expr="mode"/>
       <log label="task" expr="task"/>
     </onentry>
     <transition event="event" target="S13"/>
     <transition event="task" cond="mode eq 'S2' and task ne null" target="S2"/>
   </state>
   <state id="S13">
     <transition event="event" target="S11"/>
   </state>
 </state>

 <state id="S2">
   <initial>
     <transition target="S2Router"/>
   </initial>
   <transition event="S2.done" target="S1history"/>

   <state id="S2Router">
     <transition cond="task eq 'S21'" target="S21"/>
     <transition cond="task eq 'S22'" target="S22"/>
   </state>


   <state id="S21">
     <initial>
       <transition target="S21a"/>
     </initial>
     <state id="S21a">
       <transition event="event" target="S21b"/>
     </state>
     <state id="S21b">
       <transition event="event" target="S2final"/>
     </state>
   </state>

   <state id="S22">
     <transition event="event" target="S2final"/>
   </state>

   <state id="S2final" final="true"/>

 </state>

</scxml>

I configured state S1 to have history, thus allowing final substates
within S2 to return to the approriate calling state. Also, instead of
attempting to understand the event thrown within S12 when the S2Router
runs, I throw a generic "task" event and set the "task" variable with
the corresponding task. Within the router, I am easily able to
determine the appropriate task and route to the proper substate
accordingly.

This approach should also allow me to move the entire S2 state
definition into an external file, which has been my plan from the
beginning... This is why I wanted to keep the knowledge of the
inner-workings of state S2 out of state S1.

Thanks for your pointers, especially the history one.

Jon Brule


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to