Thanks for the clarification! I digressed when I thought about transitions in action states and I see the discussion was about transitions in stable states.
-Nestor ----- Original Message ---- From: Rahul Akolkar <[EMAIL PROTECTED]> To: Jakarta Commons Users List <email@example.com> Sent: Monday, July 2, 2007 12:58:15 PM Subject: Re: [SCXML] Querying if an event would cause a transition On 7/2/07, Nestor Urquiza <[EMAIL PROTECTED]> wrote: > Hi Rahul, > > In "Action States" you do have custom actions with side effects and they > result in variables part of guard transitions that will decide the final > stable state. I am talking about SCXML used as WEB Controller of course, in > other domains it could be like you just said but not in WEB where being used > as Controller, "actions" are needed and they of course are not side effect > free. > > Do you agree? > <snip/> Sure. But we're digressing, we were talking about the act of figuring out which transitions would be followed, not actually following any transition (or executing any custom action) at all. We were only discussing the act of determining the first transition(s) to be followed (the cascading effect of that transition leading to an action state and further transitions out of that action state is out of scope). -Rahul > If not, could you please provide a "side effect free" implementation of the > following use case? > > 1. User is subscribing to a service using a WEB application. It is mandatory > to send a password to his cellphone to verify the user is who he says. > 2. If the password is succesfully sent, the final state will be PIN_SENT. > 3. If for the contrary the password cannot be sent the FSM will stay in the > current state USER_PROFILED. > > We talked before about action states to solve postconditions. The > introspection mechanism would work simply fine for preconditions but not for > postconditions IMHO. > > Thanks, > > -Nestor > > ----- Original Message ---- > From: Rahul Akolkar <[EMAIL PROTECTED]> > To: Jakarta Commons Users List <firstname.lastname@example.org> > Sent: Thursday, June 28, 2007 12:54:48 PM > Subject: Re: [SCXML] Querying if an event would cause a transition > > On 6/28/07, Nestor Urquiza <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Not to mention that some custom actions could have to be evaluated before > > knowing which transition will apply. > > > > It might mean that some side effects could come into scene, and if they do > > the "introspection mode" cannot be used. > > > <snip/> > > Actions aren't executed unless a transition is actually followed, so > we should be OK there. However, the guard conditions on candidate > transitions would need to be evaluated, and they would need to be > side-effect free (as they should be). > > In other words, the act of identifying which transition(s) should be > followed is idempotent. > > -Rahul > > > > Thanks, > > > > -Nestor > > > > ----- Original Message ---- > > From: Rahul Akolkar <[EMAIL PROTECTED]> > > To: Jakarta Commons Users List <email@example.com> > > Sent: Wednesday, June 27, 2007 11:05:54 AM > > Subject: Re: [SCXML] Querying if an event would cause a transition > > > > Please prefix the email subject with [SCXML], since this mailing list > > is shared across all Commons components. I've added the prefix here. > > > > 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 :-) > > > > -Rahul > > > > > > > Thanks, > > > chris > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]