On 5/21/07, Nestor Urquiza <[EMAIL PROTECTED]> wrote:
Hi Rahul,
Talking about this I do not know if I posted about it before ( lazy now to search in the archives )
but at some point I ( at least ) thought about a special event let us say "app.error"
that I was hoping to use from a custom action for example to provide an "exception"
mechanism.
In a glance imagine your custom action needs to stop the normal course of your SCXML
code. I was hoping to use the type ERROR to define a special event called
"app.error" that would be included in the transition element to specify where
to go when an unexpected exception occurs.
My guess a while ago was that it would be great to make commons-SCXML "exception
aware" meaning that if for some reason an event of ERROR type is raised the complete
state machine would stop processing the current logic triggerred by a regular event and
would then proceed to the transitions to move the FSM to a state corresponding to the
error event transition target.
Makes sense?
<snip/>
Yes, users can leverage the event types (either existing or new /
user-defined) to have application-specific semantics, as you indicate
above. However, Commons SCXML itself does not use the type
information.
-Rahul
Thanks,
-Nestor
----- Original Message ----
From: Rahul Akolkar <[EMAIL PROTECTED]>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Sent: Monday, May 21, 2007 1:06:18 PM
Subject: Re: [SCXML] Event types
On 5/20/07, Hanh-Missi Tran <[EMAIL PROTECTED]> wrote:
> Hi
>
> A TriggerEvent object is associated with a type (CALL_EVENT,
> SIGNAL_EVENT, ..) but I don't know what they are used for. I look in
> the source code but whenever an event is handled, its type is not used
> (I'm wrong ?). So can someone tell me what they may be used for ?
>
<snip/>
You are correct, the type information is not used.
One of the intents of providing that was to use it as potential basis
for priority (for example, a CHANGE_EVENT, since its usually a derived
event, would have a lower priority etc.) -- but that was never
realized in code (or spec).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
