commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fasih" <fasihullah.ask...@baypackets.com>
Subject Re: [SCXML] Default Transitions
Date Sun, 09 Apr 2006 00:30:54 GMT
<quote>
 * Check before and after status of executor while firing events, and
fire an "application.default" event if the trigger is inconsequential
(can do this with current nightlies)
</quote>
I dont think that this is gonna work, I can actually want to be in the same 
state, in which case, I would add a no action transition. However the idea 
of firing something like transition.inconsequential was neat (StateEngine 
would know exactly that there is no transition, not even a dummy one). I 
will use the latest nightlies.

+Fasih
----- Original Message ----- 
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Sent: Saturday, April 08, 2006 12:53 PM
Subject: Re: [SCXML] Default Transitions


On 4/8/06, Fasih <fasihullah.askiri@baypackets.com> wrote:
> Hmm... That src idea was cool. Though I find the superstate concept 
> better.
<snip/>

Sure, its a matter of style, in fact the "superstate" is much
easier/efficient for the parsing bits. The end effect is usually the
same if you squint at it long enough though ;-)


> I can easily do
>   <state id="setup-call">
>    <initial>
>        <transition target="create-call"/>
>     </initial>
>    <state id="create-call">
>     <onentry>
>    <ccxml:createcall dest="accessnumber" name="line1"/>
>   </onentry>
>      <transition event="connection.connected" target="waiting-for-ivr"/>
>    </state>
>    ...
>  <!-- Here, though I would have loved to do a event="*" types of a usage..
> that is, any event not handled by a substate, does not look like that it
> would be possible/-->
<snap/>

There is no elegant construct for this in SCXML. Indeed, it is not
possible to graphically represent this transition in most UML tooling,
nor does such a concept exist in greater state chart theory, AFAIK.
There is no premise that an event *must* cause something to happen,
and it is perfectly acceptable to have an event do nothing to a state
machine's current status (I call these inconsequential events).

In order to get what you need here, there are multiple options (not a
complete list):

 * Complementary conds on transitions (ugly hack, not scalable)

 * Check before and after status of executor while firing events, and
fire an "application.default" event if the trigger is inconsequential
(can do this with current nightlies)

 * We should modify the SCXMLExecutor's triggerEvent() method itself
to offer this feedback, so the tedium of checking the before/after
status will be eliminated. To the effect of:

 <pseudo>
  boolean inconsequential = exec.triggerEvent(...);
  if (inconsequential) {
   exec.triggerEvent(defaultEvent);
  } else {
   //optionally, do something else
  }
 </pseudo>

 This approach was used here [1], though I never got around to pushing
it into the nightlies.


>   <transition event="connection.failed" target="error"/>
>  </state>
>  <state id="error" final="true">
>  ...
>  </state>
> </scxml>
>
> Instead of putting a src on each of the state to do the error transition??
> (i.e. If I am not wrong in understanding the concept!)
>
<snip/>

Lets say we have a state machine defined via a SCXML document
inner.scxml. To add a candidate transition across the board for this
state machine, we would do:

outer.scxml:

<scxml ... initialstate="inner">

 <state id="inner" src="inner.scxml">
  <transition event="application.error" target="error"/>
 </state>

 <state id="error" final="true"/>

</scxml>

HTH,
-Rahul

[1] http://people.apache.org/~rahul/shale/dialog-delegation/


> +Fasih
>
<snip/>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org





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