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] History state
Date Wed, 08 Apr 2009 03:03:09 GMT
On Mon, Apr 6, 2009 at 4:24 PM, Ouyang, Landon - ES/RDR -Gil
<Landon.Ouyang@itt.com> wrote:
>>> In TopState  (This is what I don't want!!)
>><snip/>
>>
>>This seems off, TopState isn't part of the least common ancestor so shouldn't be entered.
If you can attach a JUnit test case to JIRA, I'll have a look.
>
> This is why I asked the question.  It was my understanding that the super states of
State1 (TopState in this case) should not be entered and their entry actions should not be
executed.  I did not mean to include State1 in the list of unwanted functionality.
>
<snip/>

Yup, so State1 is expected but TopState isn't (if thats what you are seeing).


> I am new to Java and have not used JUnit yet.  Can you explain what you would like to
see in the JUnit test; events fired, transitions taken, state history, or something else?
>
<snap/>

There are JUnit tests buried in here:

  http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/

which you can use as examples. Generally, anything that will help us
creating a test case is welcome -- so just a complete SCXML document
with the sequence of events and expected vs. observed behavior is
enough in the report if you want to skip writing a complete JUnit
test.

-Rahul



> --
> Landon Ouyang
> Senior Design Engineer
> ITT Electronics Systems, Radar Systems - Gilfillan
> 7821 Orion Ave,
> Van Nuys, CA 91406
> (818) 901-2982
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Thursday, April 02, 2009 6:25 PM
> To: Commons Users List
> Subject: Re: [SCXML] History state
>
> On Thu, Apr 2, 2009 at 5:43 PM, Ouyang, Landon - ES/RDR -Gil
> <Landon.Ouyang@itt.com> wrote:
>> My apologies for not modifying the Subject header in my last e-mail (reproduced below).
>>
> <snip/>
>
> Thanks for correcting. Response below.
>
>
>> --
>> Landon Ouyang
>> Senior Design Engineer
>> ITT Electronics Systems, Radar Systems - Gilfillan
>> 7821 Orion Ave,
>> Van Nuys, CA 91406
>> (818) 901-2982
>>
>> -----Original Message-----
>> From: Ouyang, Landon - ES/RDR -Gil [mailto:Landon.Ouyang@itt.com]
>> Sent: Thursday, April 02, 2009 2:08 PM
>> To: Commons Users List
>> Subject: RE: [SCXML] getting set datats in the datamodel
>>
>> I am trying to implement a history state.  It does work, returns to the calling
state, however it enters all the super states before getting to the calling state.  Which
also calls entry actions (when there are entry actions).  This is not the behavior I was
expecting.  Can you explain to me how to prevent this?
>>
> <snap/>
>
> In effect, transitions to histories are not much different from
> regular transitions, barring the dynamic nature of the transition
> target.
>
> The corresponding executable content (exit, transition, entry) will be
> called. If you want other behavior, you can control blocks of
> executable content using the <if> container and appropriate
> conditions. So, for example -- the first entry into the composite
> state containing the history updates some part of the datamodel, and
> latter entries guard the executable content using <if> that checks for
> the said datamodel update.
>
>
>> Below is the command line output from a small program that accepts trigger events
and has a listener attached to the states that outputs the current state.
>> [spalmisano@linuxserver src]$ run.sh
>> Default scxml file is: HistoryTest.scxml
>> Enter path to over-ride (or enter to continue):
>> trigger>TO_STATE12
>> In State12
>> trigger>TO_STATE32
>> In State3
>> In State32
>> trigger>STATE32_TO_HISTORY
>> In TopState  (This is what I don't want!!)
> <snip/>
>
> This seems off, TopState isn't part of the least common ancestor so
> shouldn't be entered. If you can attach a JUnit test case to JIRA,
> I'll have a look.
>
>
>> In State1    (This is what I don't want!!)
> <snap/>
>
> This is as expected. As mentioned before, you may have to guard
> executable content via application logic.
>
> -Rahul
>
>
>> In State12   (This is what I do want)
>> trigger>
>>
>>
>> SCXML file used:
>>
>> <?xml version="1.0"?>
>> <scxml xmlns="http://www.w3.org/2005/07/scxml" xmlns:my="http://www.company.com"
xmlns:uml="http://schema.omg.org/spec/UML/2.1.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
version="1.0" initial="StateMachineInitial">
>>  <state id="TopState">
>>    <state id="State3">
>>      <state id="State31">
>>        <transition event="STATE31_TO_HISTORY" target="S1History"/>
>>      </state>
>>      <state id="State32">
>>        <transition event="STATE32_TO_HISTORY" target="S1History"/>
>>      </state>
>>      <initial id="State3Initial">
>>        <transition target="State31"/>
>>      </initial>
>>    </state>
>>    <initial id="TopStateInitial">
>>      <transition target="State1"/>
>>    </initial>
>>    <state id="State1">
>>      <state id="State12">
>>        <transition event="TO_STATE32" target="State32"/>
>>        <transition event="TO_STATE11" target="State11"/>
>>      </state>
>>      <state id="State11">
>>        <transition event="TO_STATE31" target="State31"/>
>>        <transition event="TO_STATE12" target="State12"/>
>>      </state>
>>      <history id="S1History" type="deep">
>>        <transition target="State11"/>
>>      </history>
>>      <initial id="S1Initial">
>>        <transition target="State11"/>
>>      </initial>
>>    </state>
>>    <transition event="END" target="StateMachineFinal"/>
>>  </state>
>>  <state id="StateMachineInitial">
>>    <transition target="TopState"/>
>>  </state>
>>  <final id="StateMachineFinal"/>
>> </scxml>
>>
>> --
>> Landon Ouyang
>> Senior Design Engineer
>> ITT Electronics Systems, Radar Systems - Gilfillan
>> 7821 Orion Ave,
>> Van Nuys, CA 91406
>> (818) 901-2982
>>
>> This e-mail and any files transmitted with it may be proprietary and are intended
solely for the use of the individual or entity to whom they are addressed. If you have received
this e-mail in error please notify the sender.
>> Please note that any views or opinions presented in this e-mail are solely those
of the author and do not necessarily represent those of ITT Corporation. The recipient should
check this e-mail and any attachments for the presence of viruses. ITT accepts no liability
for any damage caused by any virus transmitted by this e-mail.
>>
>

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


Mime
View raw message