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 
>> without that transition occuring? Including evaluation of transition
>> conditions?
> While the idea is interesting, we do not have such an "introspection 
> 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

Reply via email to