On Mon, Mar 9, 2009 at 9:44 AM, Armel SORO wrote: > Thank you for this input, Rahul! > It sounds clear now! > However, is it normal that, after having defined my own Invoker > Implementation (by implementing the Invoker JAVA interface as you said), the > cancel() method be called instead of the parentEvents() one when I try to > trigger the special done event "externalActivity.invoke.done" to the derived > engine? > Invoker#cancel() is always called when the parent state for the is being transitioned out of. This is particularly useful in scenarios like multiple orthogonal regions in a , where the transition may actually be in a sibling state of the one that contains the . Implementations should perform any associated cleanup / release resources here. Optionally, a cancel response event may be issued back to the parent. Invoker#parentEvents() "autoforwards" any events from the parent to all active invoked processes. It has no particular role in the invoke completion or termination stage. -Rahul > Regards, > > -- > Armel > > > 2009/3/6 Rahul Akolkar > >> On Fri, Mar 6, 2009 at 5:11 AM, Armel SORO >> wrote: >> > Hi, >> > >> > Since I am new to SCXML, I have some questions to ask: >> > First, is it possible to automatically trigger an event from a derived >> > engine to a main engine? >> >> >> In terms of current implementation, the only event that you can rely >> on is the $stateId.invoke.done event on completion of the 'child' as >> you use below (on the separate note, that event name is probably going >> to be changed in the next draft of the spec). >> >> There have been discussions about triggering events from invoked / >> child state machines to the parent (like you ask above), and I think >> the next draft will also draw out a mechanism to trigger an event on >> the parent using syntax similar to: >> >>   >> >> Once that is fleshed out in the spec, the Commons SCXML implementation >> will support it. Interim, you can define your own Invoker >> implementation to help with this (and use that instead of the >> SimpleSCXMLInvoker, which is the default). >> >> >> > Secondly, how can we handle "unexpected" events (events not taken into >> > account) in a given state machine? >> > >> >> >> State machines don't really consider unexpected events to be any >> error, so these have to be coded by the author a bit defensively. For >> example, if such handling is necessary, this can be done by providing >> a composite parent state with a catch-all transition that is taken if >> none other are matched (this transition can handle the unexpected >> events using executable content as necessary for the use case). >> >> To illustrate, we can go from this which ignores unexpected events: >> >> >> >>   >>  ... >>   >> >>   >>  ... >>   >> >>  ... >> >> >> >> to this which provides the said catch-all transition: >> >> >> >>   >> >>     >>       >>     >> >>     >>    ... >>     >> >>     >>    ... >>     >> >>    ... >> >>   >> >> >> >> >> > Any answer to the questions above would be appreciated to deal with the >> > following case: >> > I have a main engine that is responsible for managing a given SCXML >> > document. A new engine is instantiated each time an external activity is >> > invoked in this document. >> > For example, the main SCXML document looks like this: >> > >> > >> >   >> >       >> >           >> >       >> >       >> >   >> >   >> >      ... >> >   >> >   . .. >> > >> > >> > So, invoking the external activity "SRC" causes the main engine to >> > instantiate and launch a derived engine that has the state machine below: >> > >> > >> >   >> >     >> >       >> >     >> >   >> >   >> > >> >   >> >   >> >   >> > ... >> > >> > >> > What I want is that once this derived engine is triggered the event >> > "WebSRC.invoke.done", it raises the event "SRC.invoke.done" to the main >> > engine. >> >> >> Makes sense, should be happening. >> >> >> > I also want the derived engine to forward "unexpected" events to its >> > parent engine. >> > >> >> >> See above. >> >> -Rahul >> >> >> > Thanks in advance for ideas! >> > >> > >> > -- >> > Armel SORO >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org >> For additional commands, e-mail: user-help@commons.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@commons.apache.org For additional commands, e-mail: user-help@commons.apache.org