commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [SCXML] Querying if an event would cause a transition
Date Tue, 24 Jul 2007 18:38:22 GMT
On 7/24/07, Christopher Giblin <CGI@zurich.ibm.com> wrote:
> Hi,
> Update: In the  meantime, I have implemented a TransitionDetector class
> which implements SCXMLListener and is registered with SCXMLExecutor.
> It is only slightly odd to program:
>
>         transitionDetector.reset();
>         fsmExecutor.triggerEvent(ev);
>         System.out.println("Transition : " + transitionDetector
> .isTransitionOccurred());
>
<snip/>

Indeed. On the plus side, that can work off of the latest release.


> That gives me a tactical solution for the time being. If I find that a
> query, as suggested in my original post, really is required, I will get
> back.
>
<snap/>

I think in the longer term it will be possible to offer that feedback
via the SCXMLExecutor#triggerEvent() method(s), which currently have a
void return type (they could either return a boolean or the actual
list of transitions followed -- which could be empty).

This will require a major release (v1.0) if implemented, due to the
change in method signature. If you want to make sure this stays on the
radar, please file a ticket in JIRA [1].

-Rahul

[1] http://jakarta.apache.org/commons/scxml/issue-tracking.html




> Thanks, chris
>
>
> Christopher Giblin/Zurich/IBM wrote on 07/24/2007 12:00:36 PM:
>
> > Hi,
> >
> > Sorry for the delayed response. My remarks below.
> >
> > > Please prefix the email subject with [SCXML], since this mailing list
> > > is shared across all Commons components. I've added the prefix here.
> >
> > Thanks - I will be sure to in the future.
> >
> > > On 6/27/07, Christopher Giblin <CGI@zurich.ibm.com> wrote:
> > >>
> > >> Hi,
> > >> I am new to Commons SCXML.
> > >> Is it possible to determine whether an event would result in a
> transition,
> > >> without that transition occuring? Including evaluation of transition
> > >> conditions?
> > ><snip/>
> > >
> > > While the idea is interesting, we do not have such an "introspection
> mode".
> > >
> > > It wouldn't take too much effort to implement it, but:
> >
> > > a) Would probably increase the code smell factor a tad (if in
> > > introspection mode, then follow transition else just report back etc.)
> >
> > > b) Would require some API additions that might warrant a major
> release.
> >
> > > If you don't mind sharing in this public forum, why do you need such
> > > introspection? The SCXML specification doesn't talk about this.
> > > Understanding that interaction pattern may or may not help better
> > > answer the question, we will have to see :-)
> >
> > I am using SCXML to describe allowable states for an application.
> > Every event should result in a state transition. If no transition,
> > then I need to raise an error. Adding error states to the state
> > machine complicates it significantly. By comparison, simply
> > expressing all allowable transitions is more elegant. This requires
> > that the engine can be queried with  an event to determine if it
> > would result in a transition. By default, SCXML ignores non-
> > applicable events, remaining in the current state. Remaining in the
> > same state is ok, but I need to know if an event transition occurred
> > or not, as said. One approach would be to register as a listener to
> > determine if a transition occurred. This results in an awkward
> > programming style, however, further compounded by my app having
> > perhaps hundreds of state machines. A program would be easier to
> > read if one could ask the engine if the event leads to a transition.
> >
> > I also considered clone the state machine, listening and then
> > triggering the event. Too much overhead, though. My code must also
> > be efficient.
> >
> > Or do you see a better way of dealing with this?
> >
> > Thanks, chris
> >
> >
> >
> > > -Rahul
> >
>

---------------------------------------------------------------------
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