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] targetless transitions / event handling / accessing event payload
Date Tue, 30 Dec 2008 09:30:45 GMT
On Mon, Dec 29, 2008 at 6:45 AM, Jaroslav Pullmann
<jaroslav.pullmann@fit.fraunhofer.de> wrote:
>
>  Dear Rahul, dear all,
>  I'd like to use global targetless transitions to handle events occurring
>  asynchronously without leaving the context of the current state. Thus
> common
>  business logic (executable content within the transition) is inherited or
>  overwritten locally by any substate. It allows for chaining via
> send/transition
>  pipes for more complex, conditional behaviour. Since the transitions are
> defined
>  in a different, global scope, data are passed either via global datamodels
> or via
>  the implicit event payload. My use case is a state machine, where some
> events should
>  by handled without the "side effect" of triggerring a state transition (the
> main
>  execution path) asynchronously as they arrive from multiple clients
> interacting
>  with the SCXML session (e.g. error handling, views on datamodel and current
> status ...)
>
>  I encounter problems when trying to send and evaluate the event payload.
> There seems to be
>  no _eventdata available within the transition handling the event "view",
> although the
>  parameter "text" is obviously declared. This code is run with Commons SCXML
> v0.9:
<snip/>

You've run into an implementation subtlety, wherein Commons SCXML
treats <send> events with SCXML targettype (also the default) and no
delay to be equivalent to internal events -- of which there can be
many in an execution step of the state machine (other internal events
include .entry, .exit and .change events defined by Commons SCXML).
And since there can be more than one internal event in a step, the
event data is stored in a map keyed by the event name. This behavior
deviates from the current WD description and will need to get
corrected in a future release.

For usage and syntax, you can check out these samples to see how its
done in v0.9 (long, possibly fragmented URLs below):

  http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/eventdata-03.xml

  http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/eventdata-04.xml

One additional minor comment about some of the <log> statements below:


>
>      <scxml initialstate="main" version="1.0"
> xmlns="http://www.w3.org/2005/07/scxml">
>        <state id="main">
>
>          <initial>
>            <transition target="sub1" />
>          </initial>
>
>          <datamodel>
>            <data id="text" expr="'TEXT MESSAGE'"></data>
>          </datamodel>
>
>          <!-- event handler processing the event payload without performing
> a transition -->
>          <transition event="view">
>            <log expr="'viewing text message: '"/>
>            <log expr="_eventdata"/>
>            <log expr="text"/>
>            <!-- chained  handler -->
>            <if cond="_eventdata == null"><send
> event="'view_specific'"/></if>
>          </transition>
>
>          <transition event="view_specific">
>            <log expr="'no _eventdata found'"/>
>          </transition>
>
>          <state id="sub1" final="true">
>            <onentry>
>              <log expr="'sending text message: '+text"/>
<snap/>

Note you can use the 'label' attribute of the <log> element here
instead so the above could be authored as:

  <log label="sending text message" expr="text"/>

which better separates out the label in the document and would log this:

  INFO: sending text message: TEXT MESSAGE

instead of this:

  INFO: null: sending text message: TEXT MESSAGE

Though I'd say we shouldn't be printing null labels anyway (I'll try
to remember to make that change tomorrow).

-Rahul



>              <send event="'view'" namelist="text" />
>            </onentry>
>          </state>
>
>        </state>
>      </scxml>
>
>
>  It produces the following log statements:
>
>      Dec 29, 2008 10:42:12 AM
> org.apache.commons.scxml.env.SimpleSCXMLListener onEntry
>      INFO: /main
>      Dec 29, 2008 10:42:12 AM org.apache.commons.scxml.model.Log execute
>      INFO: null: sending text message: TEXT MESSAGE
>      Dec 29, 2008 10:42:12 AM
> org.apache.commons.scxml.env.SimpleSCXMLListener onEntry
>      INFO: /main/sub1
>      Dec 29, 2008 10:42:12 AM org.apache.commons.scxml.model.Log execute
>      INFO: null: viewing text message:
>      Dec 29, 2008 10:42:12 AM org.apache.commons.scxml.model.Log execute
>      INFO: null: null
>      Dec 29, 2008 10:42:12 AM org.apache.commons.scxml.model.Log execute
>      INFO: null: TEXT MESSAGE
>      Dec 29, 2008 10:42:12 AM
> org.apache.commons.scxml.env.SimpleSCXMLListener onTransition
>      INFO: transition (event = view, cond = null, from = /main, to = /main)
>      Dec 29, 2008 10:42:12 AM org.apache.commons.scxml.model.Log execute
>      INFO: null: no _eventdata found
>      Dec 29, 2008 10:42:12 AM
> org.apache.commons.scxml.env.SimpleSCXMLListener onTransition
>      INFO: transition (event = view_specific, cond = null, from = /main, to
> = /main)
>
>
>  It's probably my fault using a wrong syntax. Could you please suggest a way
> how to:
>
>    1) access the simple string content of _eventdata ?
>
>    2) access XML _eventdata via XPath ?
>
>    3) send a subtree of an XML data model along with an event ?
>
>  To handle 3) and transition chaines passing arbitrary data chunks via named
>  parameters the <send> element, like <invoke>, could use <param> child
> elements
>  to explicitly declare its data interface decoupled from the datamodel ?
>
>  Is there any reason <event>, unlkike <send>, does not support any sort of
> parametrization
>  in the current WD and such the event name itself has to encode the
> respective parameter-value
>  information ?
>
>    Many thanks for your support
>     Jaro
>
>

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


Mime
View raw message