On 4/7/06, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> wrote:
> I found that if we have a multiple transition events within a state and any
> without a guard condition get processed before reaching the guard conditions
> of the other transition events. Is this the expected behavior?
>
> For instance:
>
> <state id="1">
> <transition event="menu"></transition>
> <transition event="choice" cond="${request.input == 'help'}"> do something /
> target state = 2 </transition>
> <transition event="choice" cond="${request.input == 'call'}"> do something
> else / target state=2 </transition>
> </state>
>
> <state id="2">
> ... stuff
> </state>
>
>
> It never processes the guard conditions, however if I place the first event
> without the guard condition AFTER the two with, even though they have
> different event names, it works?
>
<snip/>
What event is being fired for this scenario when you're in state 1? If
its "menu", there is only one candidate transition there, if its
"choice" then there is no ambiguity either since the conds will ensure
that at most one transition is followed.
Sorry, it seems I didn't quite get that. In order to be able to tell
you why the ordering would play any role in this particular scenario,
could you please post the smallest complete SCXML document and the
event name(s) that are fired on the state machine, in the correct
order, so I can reproduce your observations? Thanks in advance.
> Any reasoning behind this. I get odd errors where it actually creates 2
> states simultaneously.
>
<snap/>
Trying to navigate into two sibling states that are not regions
(children of a parallel) is semantically a folly in SCXML. Probably a
more complete snippet will explain why that is happening here.
> ======
>
> Also, what are the rules with using the single quotes within double quotes
> for variables. When referencing the variables I set expr="'something'" it
> actually passed 'something' instead of something ???
>
<snip/>
Depends on the expression language. If you're using EL, you don't need
the single quotes for assigning String constant values, since the only
expressions are those wrapped in ${...}, so any bits that don't match
default to a constant String:
<assign name="foo" expr="bar"/> <!-- EL, no single quotes -->
but if you're using JEXL the single quotes are needed otherwise the
intended String literal will be evaluated as an expression (and
probably evaluate to null), so:
<assign name="foo" expr="'bar'"/> <!-- JEXL, single quotes -->
-Rahul
>
> Thanks,
>
>
> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]