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" <[EMAIL PROTECTED]>
To: "Jakarta Commons Users List" <[email protected]>
Sent: Saturday, April 08, 2006 12:43 AM
Subject: Re: [SCXML] Default Transitions
On 4/7/06, Fasih <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
