commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Herring <bherr...@openmethods.com>
Subject Re: [SCXML] Parallel parent states resetting to initial substates?
Date Fri, 08 Jan 2010 22:37:13 GMT
OK, I found that it is indeed a feature (Section 3.3.3 of the SCXML  
spec), but I still need the behavior I describe in my original email.   
In an attempt to fix the problem, I added history states to the two  
parallel parent states, like this:

	<parallel id="open_channel">
	    <state id="agent_status">
	        <initial>
	        	<transition target="resume_agent_status"/>
	        </initial>	
	        <transition event="tester.Pready"   target="ready"/>
	        <transition event="tester.PnotReady"   target="not_ready"/>
			<state id="ready">
		        <transition event="tester.notReady"   target="not_ready"/>
			</state>
			<state id="not_ready">
		        <transition event="tester.ready"   target="ready"/>
			</state>
			<history id="resume_agent_status" type="deep">
				<transition target="ready"/>
			</history>
		</state>
	    <state id="channel_status">
	        <initial>
	        	<transition target="resume_channel_status"/>
	        </initial>	
	        <transition event="tester.Pdial"   target="on_call" />
	        <transition event="tester.Phangup"   target="off_call" />
			<state id="off_call">
		        <transition event="tester.dial"   target="on_call" />		
			</state>
			<state id="on_call">
		        <transition event="tester.hangup"   target="off_call" />
			</state>
			<history id="resume_channel_status" type="deep">
				<transition target="off_call"/>
			</history>
		</state>
	</parallel>

However, the result appears to be similar but with some additional  
strange behavior if I transition to a state I'm already in - I suspect  
the transitions and histories are conflicting with each other. (?)

Still wondering if there's any way to use "catch-all" transitions in  
parent states when the parent states are parallel.

- Bill


On Jan 8, 2010, at 10:25 AM, Bill Herring wrote:

> I'm working with a state model with two parallel states that each  
> have substates:
>
> 	<parallel id="channel">
> 	    <state id="agent_status" initial="ready">
> 	        <transition event="parent.goReady"   target="ready"/>
> 	        <transition event="parent.goNotReady"   target="not_ready"/>
> 		<state id="ready">
> 	        <transition event="goNotReady"   target="not_ready"/>
> 		</state>
> 		<state id="not_ready">
> 	        <transition event="goReady"   target="ready"/>
> 		</state>
>            </state>
>
> 	    <state id="channel_status" initial="off_call">
> 	        <transition event="parent.dial"   target="on_call" />
> 	        <transition event="parent.hangup"   target="off_call" />
> 		<state id="off_call">
> 	        <transition event="dial"   target="on_call" />		
> 		</state>
> 		<state id="on_call">
> 	        <transition event="hangup"   target="off_call" />
> 		</state>
> 	     </state>
> 	</parallel>
>
> When I trigger transitions with the "leaf events" (goNotReady,  
> goReady, dial, and hangup) everything works as I would expect - the  
> two parallel states transition between substates independently.   
> However, if I trigger transitions using the "parent  
> events" (parent.X), the transition occurs in the one parallel  
> substate and the other parallel substate apparently "resets" to its  
> initial state.  As a concrete example, if I trigger  
> "parent.goNotReady" followed by "parent.dial" I end up in "on_call"  
> and "ready" (vs. "on_call" and "not_ready", which I would be in if I  
> has used "goNotReady" and "dial" instead).
>
> Is this a feature or a bug?  Is there a way to get the same behavior  
> in both cases?  I realize that in this trivial example there's no  
> real advantage to putting the transitions in parent states, but I  
> have a much more complex state model where I want to put "catch all"  
> transitions in parent states and this behavior is stopping me from  
> doing that.
>
> Thanks,
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>











---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message