About the _eventdata the question is if given for
example:
<transition event="v3:HelloWorld2.done"
condition="printed eq yes and disconnected eq true">
<!--
we use _eventdata to access data in the
event we're processing
-->
<ccxml:disconnect
connectionid="_eventdata.getConnectionId"/>
</transition>
_eventdata.getConnectionId (getConnectionId is an
event supported by the object represented by
_eventdata variable) would be executed before the
condition is tested.
In the example I am assuming an internal communication
to happen when _eventdata.getConnectionId set the
variable disconnected = true.
In any case I think I am answering my question and the
answer is nope you cannot expect
_eventdata.getConnectionId to set a variable that will
in turn be checked in the condition just because the
_eventdata assignment is a child of the transition
node and so that particular transition node must be
selected in order the method
_eventdata.getConnectionId to be called. Am I missing
something or seems like at the end the appropiate
solution for me is to create Action States?
Thanks,
Nestor
--- Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 4/20/06, Nestor Urquiza <[EMAIL PROTECTED]>
> wrote:
> > So you think the approach of calling a method as
> part
> > of the condition is a valid alternative or because
> of
> > the fact that it is relying on a common way of
> > evaluating boolean expressions that still jexl
> might
> > not guarrantee you think it is a weak approach and
> I
> > would go with intermediate Action States?
> >
> <snip/>
>
> IMO, whether you choose an intermediate state should
> depend upon:
>
> * Amount of work done in executable content within
> the method you're
> calling (more work implies an action state
> preference, since
> transitions are more or less instantaneous, but this
> is somewhat of a
> theoretical argument).
>
> * Amount of logical outcomes coming out of the
> method you're calling.
> If on a certain event, you need to call a method
> that can come back
> with different logical outcomes that dictate the
> transition target,
> you need an action state. As an example, see
> "checkCookie" state in
> the Commons SCXML rendition of the Shale usecases
> log-on dialog [1].
>
> You will have to try short-circuiting in JEXL
> yourself, sorry I don't know.
>
>
> > Also, about payload/_eventdata I do not understand
> if
> > the method going to be called before the
> conditions
> > are evaluated within a transition?
> <snap/>
>
> What method is that?
>
>
> > If yes then I can
> > setup variables using an _eventdata object methods
> > then test for those variables in the condition. Is
> the
> > _eventdata variable behavior already implemented
> in
> > commons?
> >
> <snap/>
>
> Yes, and is now documented as well ;-) (though
> website is not
> refreshed yet -- in a few).
>
> -Rahul
>
> [1]
>
http://jakarta.apache.org/commons/sandbox/scxml/usecases/shale-dialogs/log-on-config.xml
>
> > Thanks
> >
> <snip/>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
