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 <[EMAIL PROTECTED]> 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
