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.
Thanks,
-Nestor
----- Original Message ----
From: Rahul Akolkar <[EMAIL PROTECTED]>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Sent: Tuesday, May 22, 2007 3:47:17 PM
Subject: Re: [SCXML] Event types
On 5/22/07, Nestor Urquiza <[EMAIL PROTECTED]> wrote:
> So you mean commons-scxml users should provide their application specific
> SCXMLSemanticImpl.java? Which method should we use to use a custom one that
> lives in a different than org.apache.commons.scxml.semantics package?
>
<snip/>
No (well, depends on the specifics but that wouldn't be the first
course of action -- since that deviates from what is provided out of
the box).
To answer the other question, IIUC -- if custom SCXMLSemantics are
indeed defined, then the four argument SCXMLExecutor constructor needs
to be used.
I meant to say that event names (such as "app.error" in your example,
which should be called "error.app" IMO to better serve an event
ontology when using wild cards etc.), event types (trickier to get at)
and event payloads etc. often make more sense to the application
(rather than the library).
-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 10:58:29 PM
> Subject: Re: [SCXML] Event types
>
> 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]
____________________________________________________________________________________Fussy?
Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay
it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
