You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Fasih <fa...@baypackets.com> on 2006/04/07 18:09:46 UTC
[SCXML] Default Transitions
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. 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??
+Fasih
Re: [SCXML] Default Transitions
Posted by Fasih <fa...@baypackets.com>.
<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" <ra...@gmail.com>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Saturday, April 08, 2006 12:53 PM
Subject: Re: [SCXML] Default Transitions
On 4/8/06, Fasih <fa...@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
Re: [SCXML] Default Transitions
Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/8/06, Fasih <fa...@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
Re: [SCXML] Default Transitions
Posted by Fasih <fa...@baypackets.com>.
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" <ra...@gmail.com>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Saturday, April 08, 2006 12:43 AM
Subject: Re: [SCXML] Default Transitions
On 4/7/06, Fasih <fa...@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
Re: [SCXML] Default Transitions
Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/7/06, Fasih <fa...@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