commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <nest...@yahoo.com>
Subject Re: [SCXML] patterns for bridging
Date Thu, 20 Apr 2006 17:08:10 GMT
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?

Also, about payload/_eventdata I do not understand if
the method going to be called before the conditions
are evaluated within a transition? 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?

Thanks


--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:

> Trimming copious amounts to keep message size
> manageable ...
> 
> On 4/20/06, Nestor Urquiza <nestoru@yahoo.com>
> wrote:
> > --- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> <snip/>
> >
> > I am implementing state oriented business
> application
> > protocol ("scxml engine" + "bridge") that in fact
> will
> > be used between others by http calls ("system")
> not
> > relevant the way ... it can be GET/POST/REST/SOAP
> or
> > whatever terminology someone can come for the same
> > "Receiving calls from a client and answering them
> via
> > HTTP".
> >
> <snap/>
> 
> Thanks for that level set.
> 
> 
> >
> > Could you think about an option to avoid action
> > states?
> >
> <snip/>
> 
> Yes, as you point out below ;-)
> 
> 
> > > While you can hack most state machines to fit
> many
> > > topologies (such as
> > > by having side-effects in guard conditions), the
> >
> > Interesting, given the fact that jexl supports
> method
> > invocation ... don't you think this is a way to
> avoid
> > to much descriptive information in the scxml file?
> >
> <snap/>
> 
> It somewhat comes down to a matter of personal taste
> in readability,
> or how it was modeled. I can see the need for both
> usages, and have
> seen (and used) both.
> 
> 
> > Consider the jexl expression for example:
> > "validVar eq true and
> > contextObjectUsingTheEventName.execute()"
> >
> > Because of the simple and there you could ensure
> that
> > only if the first part is true (pre-cond) you call
> the
> > execute method of an object that is supposed to be
> in
> > the context and you know its name because it maps
> to
> > the state machine event-name and the http-call.
> The
> > result is a boolean that will complete the
> > post-condition and therefore you do not need an
> action
> > state.
> >
> <snip/>
> 
> Yup, makes sense, but Commons SCXML cannot make any
> guarantees about
> things such as whether the underlying EL used
> short-circuits compound
> boolean expressions etc.
> 
> 
> > In other words this is maybe answering the
> alternative
> > way I am looking for. And it is important to
> > understand that I am not after a side-effect but
> > specific-code in my case.
> >
> > Where I can see an example or information about
> > implementing such a mechanism? This is having jexl
> > expression that executes some java code that
> returns
> > boolean and can be used for a condition. I opened
> > another thread and I see I have responses so let
> me
> > check out them ... it is precisely related to the
> > context that I thought I need to use for this
> scenario
> > in order to set up the object that the sate
> machine is
> > supposed to use.
> >
> > Is it something the engine is doing already or
> will
> > do?
> >
> <snap/>
> 
> As you state, JEXL already does that. So Commons
> SCXML does that too
> by transitivity if you use JEXL for expressions. If
> "contextObjectUsingTheEventName" from the above
> snippet is available
> in the Context, then JEXL will take care of the
> method invocation. We
> do have examples of JSF method binding expressions
> in SCXML documents
> in the usecases, but probably none of JEXL method
> invocation. But
> there is nothing more to it than your snippet above.
> 
> -Rahul
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message