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 Sat, 08 Apr 2006 15:02:10 GMT
Hmm... That src idea was cool. Though I find the superstate concept better.
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/-->
   <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!)

+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:43 AM
Subject: Re: [SCXML] Default Transitions


On 4/7/06, Fasih <fasihullah.askiri@baypackets.com> wrote:
> Hi
> An action can emit multiple event, one of which can be an error. I dont 
> want to define an error transition for each of my states, I was going thru 
> the SCXML specs, I couldn't locate anything like a default transition. 
> However, they have
> <quote>
> Thus the most narrowly scoped transition wins. The motivation for this 
> choice becomes clear when we remember that sequential substates are 
> decompositions of the parent state. Thus S112 is a refinement of S11 and 
> S11 in turn is a refinement of S1. The innermost state thus "knows the 
> most" about the situation so its transitions are preferred to those in 
> outer states, which can be treated as defaults or fallbacks.
> </quote>
> So, to achieve a default transition, I guess defining my state engine as a 
> substate of a super state which has all the error transtions would work.
<snip/>

Thats right, you can also leverage the "src" attribute of <state> to
achieve similar results. As an example, check out the "createProfile"
state in this example (long URLs, may be fragmented):

http://jakarta.apache.org/commons/sandbox/scxml/usecases/shale-dialogs/log-on-config.xml

which actually pulls in this state machine:

http://jakarta.apache.org/commons/sandbox/scxml/usecases/shale-dialogs/edit-profile-config.xml

as the body of "createProfile" and adds a new "global" transition for
the enclosed state machine. This also has a "templating" effect where
the enclosed state machine can be reused several places with different
"decorations" around it.


> Also, another wy I was thinking of was to have an ErrorListener or 
> StateListener to alert me. Is that expected to use these for such kind of 
> a thing??
>
<snap/>

Depends ;-) This post may help:

http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114344354313954&w=2

-Rahul


>
> +Fasih
>

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