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]