On Mon, Apr 6, 2009 at 4:24 PM, Ouyang, Landon - ES/RDR -Gil <[email protected]> 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:[email protected]] > 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 > <[email protected]> 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:[email protected]] >> 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. >> [spalmis...@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: [email protected] For additional commands, e-mail: [email protected]
