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@zuri...> 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