Thanx Rahul That was really quick. I was thinking about the payload option yesternite, there is a glitch in that. As you can see, for every event I will have to keep the cond, now that sounds perfectly logical, but given my use-case that seems unneseccary. Again, coming back to my use-case, I want to test my application server; I am trying to use scxml to simulate a UA with different behaviours, further down the line I will integrate this with DBUnit to figure out if the call rating/charging, cdr etc have been written properly or not. I am not very sure if SCXML is the right thing to do this, but it does provide a solution which would be very convenient to simulate different call scenarios. Given that, adding conds does not sound very intutive.
This is another solution I was thinking of, again, I am just thinking aloud, not really thought of pros/cons of the solution: Have a scenario.xml with names&scxml for each scenario. Have a SessionManager to load each of these scxml and ascociate it with a sip dialog. Keep the root context same for each of the Executor to aid in data sharing if required. Now when an event comes, instead of "broadcasting" it to all lines, send it to the exec concerned [known to the scenario manager]. This makes each scenario stand-alone, and gives all the flexibility that SCXML has to give minus the conds which are introduced coz I have designed it that way. Any comments welcome. +Fasih -----Original Message----- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 3:24 PM To: Jakarta Commons Users List Subject: Re: [SCXML] Same event to multiple parallel states On 4/3/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 4/2/06, Fasih <[EMAIL PROTECTED]> wrote: <snip/> > > The latest SCXML WD also specifies that the special variable > "_eventdata" may be used to access data contained within the > triggering event (i.e. the payload). Thus, along the lines of the > above example, a transition may look like: > > <transition event="connection.alerting" > cond="_eventdata.line eq 1" > target="..." /> > > where the event payload defines a "line" property. This bit (exposing > payload as "_eventdata") hasn't been done for Commons SCXML yet, but > I'll do it now. Will ping this thread when am done. > <snap/> Ping, "_eventdata" should be available in 20060404 nightlies here [1]. Here [2] is a sample based on your snippet, also illustrates using a user-defined payload ("_eventdata.line" in the expressions under state2 refers to line property of user-defined payload type [3]). -Rahul (long, possibly fragmented, URLs below) [1] http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/ [2] http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/eventdata-02.xml?view=markup [3] http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/EventDataTest.java?view=markup (see ConnectionAlertingPayload type towards end of file) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
