commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [SCXML] Parallel parent states resetting to initial substates?
Date Tue, 13 Apr 2010 22:45:26 GMT
On Fri, Jan 8, 2010 at 6:37 PM, Bill Herring <bherring@openmethods.com> wrote:
> OK, I found that it is indeed a feature (Section 3.3.3 of the SCXML spec),
<snip/>

Yup, followed transition's parent state will always be exited (and if
its the base of an orthogonal region, that means all other orthogonal
region siblings will have to be exited too, given the semantics of
<parallel>).


> 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.
>
<snap/>

Add an intermediate <state> that prevents the exit from the orthogonal region.

So, instead of this pattern:

<parallel id="par">

  <state id="region1">
    <initial>
      <transition target="foo"/>
    </initial>
    <transition event="trigger"   target="bar"/>

    <!-- foo, bar and other content -->

  </state>

  <!-- other regions -->

</parallel>

use the following pattern instead:

<parallel id="par">

  <state id="region1">
    <initial>
      <transition target="intermediate"/>
    </initial>

    <!-- the following contains content of region1 before -->
    <state id="intermediate">
      <initial>
        <transition target="foo"/>
      </initial>
      <transition event="trigger"   target="bar"/>

      <!-- foo, bar and other content -->
    </state>

  </state>

  <!-- other regions -->

</parallel>

-Rahul


> - 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


Mime
View raw message