On Tue, May 17, 2011 at 8:37 PM, Ryan <rnidef...@gmail.com> wrote: > Looks like I signed up for this mailing list about 5 hours too late. Reading > today's reply from Rahul, he notes: > > "You should inject events from within a custom action by adding to the set > of derived events (param of execute method) which will be processed in a > subsequent microstep, rather than triggering another event on the executor > (if thats what you're doing)." > > Once I added the TriggerEvent to the Collection of derived events, the > transition condition evaluated to 'true' as expected. > > Is this explained in the documentation and I just missed it? I'm curious as > to when it would be desirable to trigger an event on the SCXMLExecutor > instance itself versus adding it to the derived events collection. > <snip/>
Synchronous cases like custom actions (pretty much the only case) should produce derived events (rather than attempting re-entrant triggers). Asynchronous cases like invoke or delayed sends should trigger events on the executor. If expected frequency of external triggers on a state machine is high (many per sec), its a good idea to maintain a separate synchronized event queue. Finally, there is always room for better docs, FAQ etc. -- happy to look at any suggested patches [1] for improvement. Site source is here [2]. -Rahul [1] http://commons.apache.org/scxml/issue-tracking.html [2] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/site/ > Ryan > > On Tue, May 17, 2011 at 5:22 PM, Ryan <rnidef...@gmail.com> wrote: > >> I have the following simple SCXML document: >> >> <scxml xmlns="http://www.w3.org/2005/07/scxml"; >> xmlns:my="http://www.my.com"; >> version="1.0" >> initialstate="welcome"> >> >> <state id="welcome"> >> <onentry> >> <my:play filename="welcome"/> >> </onentry> >> <transition cond="${_eventdata eq 'blah'}" target="end"/> >> </state> >> <state id="end" final="true"> >> <onentry/> >> </state> >> </scxml> >> >> My approach is to generate events from custom actions, then act on those >> events in my transitions. To test this approach, I hardcoded the generation >> of an event in my Play.class action: >> >> TriggerEvent evt = new TriggerEvent("agi.keypress", >> TriggerEvent.SIGNAL_EVENT, "blah"); >> scInstance.getExecutor().triggerEvent(evt); >> >> However, I can't seem to get the <transition/> to recognize this event. >> Here is log output as the state machine runs: >> >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdata = blah >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdatamap = {agi.keypress=blah} >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdata = null >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdatamap = null >> [org.apache.commons.scxml.SCXMLExecutor] (Asterisk-Java >> DaemonPool-1-thread-1) Current States: [] >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdata = null >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdatamap = {welcome.entry=null} >> [org.apache.commons.scxml.Evaluator] (Asterisk-Java DaemonPool-1-thread-1) >> ${_eventdata eq 'blah'} = false >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _ALL_NAMESPACES = null >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdata = null >> [org.apache.commons.scxml.Context] (Asterisk-Java DaemonPool-1-thread-1) >> _eventdatamap = {welcome.entry=null} >> [org.apache.commons.scxml.SCXMLExecutor] (Asterisk-Java >> DaemonPool-1-thread-1) Current States: [welcome] >> >> Why is the _eventdata/_eventdatamap pair being printed twice to start? The >> first time it has the event I've triggered, the second time its empty. Then >> after this, you see that the welcome.entry event triggered, then the JSP EL >> condition evaluates to false. >> >> My initial guess is that I've misunderstood the state machine algorithm, >> and my attempt to trigger an event from the <onentry/> is flawed. >> >> How should I go about this? >> >> Thanks, >> Ryan >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
