commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Herring <>
Subject Re: [SCXML] History in parallel?
Date Wed, 13 Jan 2010 23:24:42 GMT
I didn't think of that, and it's more elegant than the workaround I  
used, which was to put history tags in the talk_status, call_status,  
etc. inside the parallel state and target those histories instead of a  
single one.  Thanks for the tip!  I'll make sure I prefix future  
subject lines with SCXML too.

Also,  have another unrelated question - please let me know if you'd  
rather me post it to the list under a new subject, and I'll do so.

In my ignorance of CommonsSCXML (I picked it up a few weeks ago), I'm  
trying to programatically inject some bits of data into the datamodel  
for a state before I fire an event that will target that state.  Then  
when the transition fires and the target state is reached, a <send>  
that makes use of the datamodel (ala the namelist attribute) fires  
onentry.  The goal is to communicate data from one "client" of the  
state machine to another.

If this seems overly complicated, perhaps it is...  But assuming  
there's not a better way, my current problem is that I can modify the  
datamodel of the target easily enough, via getDataModel() and  
setDateModel().  This works fine the first time, but fails to "send"  
any new data after that because the target state's context gets  
created once and then is not updated when I change the datamodel - the  
two are out of synch.

So I need to be able to synch the two - there are public methods to  
get the root context, but how do you get the context for a specific  
state?   I guess I could just use the root context to do everything,  
but that seems clumsy, and I'm interested in how I can manipulate  
other contexts anyway (preferably without modifying the CommonsSCXML  

There are clearly other ways to structure the passing of such data,  
but I am assuming that the code that fires the transitioning event and  
the code that handles the send event have no way to communicate other  
than via the state machine.  Also, I don't want to depend on the send  
event being handled immediately after the firing of the transition  
event, even though that may be the case in my current implementation  
(i.e. another transition might happen and trigger another send before  
the current one is processed).  And, finally, though I can see ways to  
not use it, I believe <send> best reflects my intent - to send a  
message to an object/thread/program that is external to the state  
machine.  Of course, I could be wrong... :)

Thanks again for your help,

On Jan 13, 2010, at 3:40 PM, Rahul Akolkar wrote:

> Please prefix the email subject with the Commons component name when
> posting, as I've done here (since this is a shared mailing list).
> Response below ...
> On Thu, Jan 7, 2010 at 5:51 PM, Bill Herring  
> <> wrote:
>> My reading of the latest W3C working draft is that SCXML supports  
>> history
>> pseudo-states in parallel ones.   When I run my app with the SCXML  
>> model
>> below, I get:
>>        WARNING: Ignoring element <history> in namespace
>> ""
>> and then it cannot find the two resume_ targets.
>> Does Commons SCXML support history elements as parallel children?   
>> Am I
>> doing something wrong here?
> <snip/>
> The current release (v0.9) does not support history in parallel.
> Work has been done in a development branch on a version of the parser
> that does support history as used below, but its yet incomplete and
> unreleased.
> While using v0.9, I'd suggest using a state wrapper element around the
> parallel to hold the deep history.
> -Rahul
>> <?xml version="1.0"?>
>> <scxml xmlns=""
>>       version="1.0" initial="off_call">
>>        <state id="off_call">
>>                <transition event="dial" target="call_active"/>
>>        </state>
>>        <parallel id="call_active">
>>                <state id="talk_status" initial="talking">
>>                        <state id="talking">
>>                                <transition event="hold"    
>> target="held" />
>>                        </state>
>>                        <state id="held">
>>                                <transition event="retrieve"
>> target="talking" />
>>                        </state>
>>                </state>  <!-- END talk_status -->
>>                <state id="call_status" initial="on_call">
>>                        <state id="on_call">
>>                                <transition event="hangup"
>>  target="off_call"/>
>>                                <transition event="consult"
>> target="consult_active"/>
>>                        </state>
>>                        <state id="on_call_consult">
>>                                <transition event="hangup"
>>  target="off_call"/>
>>                                <transition event="alternate"
>> target="resume_consult"/>
>>                        </state>
>>                </state>    <!-- END call_status -->
>>                <history id="resume_call" type="deep"/>
>>        </parallel>  <!-- END call_active -->
>>        <parallel id="consult_active">
>>                <state id="consult_talk_status"  
>> initial="consult_talking">
>>                        <state id="consult_talking">
>>                                <transition event="hold"
>> target="consult_held" />
>>                        </state>
>>                        <state id="consult_held">
>>                                <transition event="retrieve"
>> target="consult_talking" />
>>                        </state>
>>                </state>  <!-- END consult_talk_status -->
>>                <state id="consult_status" initial="on_consult">
>>                        <state id="on_consult">
>>                                <transition event="hangup"
>>  target="resume_call"/>
>>                                <transition event="alternate"
>> target="resume_call"/>
>>                        </state>
>>                </state>    <!-- END consult_status -->
>>                <history id="resume_consult" type="deep"/>
>>        </parallel>  <!-- END consult_active -->
>> </scxml>
>> Thanks,
>> Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Bill Herring
4741 Central Street  |  Suite 285  |  Kansas City, MO  |  64112-1533
o| +1.816.283.VXML (8965) x105 |
P This email is composed of 100% recycled electrons. Please print only  
when necessary.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message