commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ingmar Kliche" <>
Subject Re: [SCXML] Automatic forward of external events to <invoke>'d components ?
Date Thu, 12 Jul 2007 22:10:50 GMT
2007/7/6, Rahul Akolkar <>:
> It is my interpretation of, quoted from your reference:
> "Note that the <invoke> element may be used to invoke an external
> SCXML interpreter to execute a different state machine. In this case,
> the external state machine acts as a set of substates of the invoking
> state. The behavior is thus similar to a complex state defined with
> <state> child elements."

Makes sense for sub machines!

One would expect substates to receive all the same events.

I had a look at the implementation of invoke again. It apears that external
events (i.e. triggerEvents()) are used to feed events into both engines.
parentEvents() uses it to feed external events occuring at the parent into
the child engine and the child engine uses it to feed *.invoke.done into the
parents engine.

But I have missed how the child machine may send events during execution to
its parent. If you also use external events (i.e. a triggerEvent) to send
events to the parent, how would you avoid that the same event is forwarded
again into the invoke'd machine?

Also I have not found how events are automatically forwarded from the child
to the parent. Assume I use a <send event="foo" targettype="scxml"/> within
the child. This would let an external event occur at the child. Now - taking
the assumption that an invoke'd child machine behaves like a complex state
within the parent - I would assume that the external event occuring at the
child is also fed into the parent.


> Makes sense, and should be possible. If you want to track this, please
> open a ticket in JIRA [1]. I may not be able to get to it for a couple
> of weeks. If you want to take a stab at it, you will have to modify
> the execute() method in oacs.model.Send. Currently, the "invokedID" is
> effectively the ID of the parent <state>, but that may need to be
> revisited as well.


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