Yes, I remember that one a year ago when I started my project ... the
Domain/Bridge/Engine definition convinced me this was the API I was looking for
when deciding how to implement a state oriented business protocol.
In fact the idea of using err.app came from that or another related post as far
as I remember. The proposed solution is then to manage with thrown by the
application events (from custom actions) where to go but as discussed before it
won't mean that the rest of the code within the onentry state won't be executed.
See the following example (borrowed from your post and arbitrarly changed to
demonstrate the issue):
<state id="foo">
<onentry>
<my:action ... />
<my:action2 ... />
</onentry>
<transition event="err.foo" target="errorstate" />
<n:transition cond="resultFromAction2 eq true" target="bar"/>
<!-- other transitions etc. -->
</state>
If "action" somehow manages its exceptional situation throwing "err.foo" event
it wont stop execution of "action2". Furthermore since chances are more than
one transition conditions/events could be stisfied the FSM could go to two
different states at the same time (errorstate and bar) which of course is not
what we want.
Our target is just to stop action, do not execute action2 and ensure *only*
event err.foo is processed as part of the transitions (perhaps because of the
fact that it has a higher priority as suggested before).
Does it make sense?
Thanks,
-Nestor
----- Original Message ----
From: Rahul Akolkar <[EMAIL PROTECTED]>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Sent: Thursday, May 24, 2007 4:10:28 PM
Subject: Re: [SCXML] Event types
On 5/22/07, Nestor Urquiza <[EMAIL PROTECTED]> wrote:
> Could you mention in your opinion at least one of the alternatives to modify
> or create a new SCXML Semantic implementation to deal with critical errors
> that are supposed to stop the normal flow of the application? The Event type
> could be one that we already saw is not going to be provided within the
> library and still seems like the best way to accomplish that goal.
>
<snip/>
I think this was discussed a couple of times so I tried to look it up
in the archives, though I can only find one reference ATM (see about a
third of the way down in following email):
http://www.nabble.com/Re%3A--SCXML--SCXMLListener-Exception-Handling-Question-p3604935.html
That along with a couple of related observations ...
* Stopping a flow is equivalent to redirecting it to a (different)
final state (than what is perceived "normal")
* Each event name, by itself, specifies a unique "type" of event
... should satisfy many usecases.
-Rahul
> Thanks,
>
> -Nestor
>
<snap/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
