Thanks Raul. So THAT'S what the W3C spec meant... :-) Makes sense, I just didn't know you could have multiple transitions w/ same event name.
Cheers, Mike -----Original Message----- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 7:57 PM To: Jakarta Commons Users List; [EMAIL PROTECTED] Subject: Re: [SCXML] EL and dynamic transition target On 12/13/05, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> wrote: > Hi Rahul, > > One more query from my guy about our next step, getting EL to work: > > ============ HIS QUESTION > " > > I tried various patterns to achieve to change the state based on guard > condition, but the <transition><target> does not work. I manage to > get the log "'IF Input was one'" etc on the selection, but the state > remains in 'state_welcome' > > I am using the URL http://localhost:8080/goomzee/Voice for testing > this. > > > First box is for event, and second is for input. The 'event' need not > be entered, based on the scxml, it is set to 'greet' > > <transition event="greet" > > <var name="cb" expr="${ConversationBeanID}" /> > <var name="ip" expr="${cb.userInput}" /> > <var name="nextState" expr="state_welcome" /> > > <log expr="'Input from cb was:' ${ip}" /> > <log expr="'Event from cb was:' ${cb.event}" /> > <if cond="${ip == 1}"> > <log expr="'IF Input was one'" /> > <assign name="nextState" expr="state_login" /> > <elseif cond="${ip == 2}" /> > <log expr="'IF Input was two'" /> > <assign name="nextState" expr="state_logoff" /> > <else /> > <log expr="'IF Other Input was :' ${ip} " /> > </if> > <log expr="'Next State var :' ${nextState}" /> > <target next="${nextState}" /> > </transition> > > " > =========== /HIS QUESTION <snip/> There is no such thing as a "dynamic" transition target in state chart theory. One needs to enumerate all potential transition targets under separate transitions. Guard conditions for transitions give us the behavior you're looking for. A state may have zero or more outbound transitions where each transition specifies: * A required target, specified at the time of authoring the state chart * An optional event, which is the event or family of events which is said to trigger a transition (i.e. make it part of the candidate transitions set at any point in time) * An optional guard condition, which must evaluate to "true" for a particular transition to be followed. * Any number of "executable actions" (such as <log>, <if> etc.) which get processed *if and only if* the transition is followed. Thus, the example above -- since it has two potential target states -- must be written out as the following (with <log> statements as needed): <transition event="greet" cond="${ConversationBeanID.userInput == 1}"> <target next="state_login" /> </transition> <transition event="greet" cond="${ConversationBeanID.userInput == 2}"> <target next="state_logoff" /> </transition> > > MY INITIAL THOUGHT: > > perhaps within the conditional block, we add another transition: > > <if cond="${ip == 1}"> > <transition> > <target next="state_logoff" /> > </transition> > <else /> > ... > </if> > > instead of assigning the variable and trying to execute at the end > after evaluation? Do you know if our attempt above should work, or is > the only way to implement by explicitly declaring the transition > within the <if>...<else>...</if> blocks? > <snap/> Actions are only meant to be executed onentry, ontransition or onexit, i.e. as children of <onentry>, <transition> and <onexit> elements. Thus, the <if>, <else> above are misplaced and will not have the desired effect. -Rahul > Rgds, > > Mike > <snip/> --------------------------------------------------------------------- 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]
