commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <>
Subject Re: [scxml] TriggerEvent.ERROR_EVENT type behavior
Date Tue, 11 Jul 2006 00:44:50 GMT
Going further thru the code and looking to some tips
from Rahul [1] I still am wondering if the only
alternative must be to author custom actions extending
 the Commons SCXML Action  abstract base class. 

In my specific case I cannot do so since I am relying
in a lot of helper method I access from objects that I
have in the Root Context and for me it is impossible
to change all those objects.

Consider for example:
<n:var name="contentSupported"
expr="userProfile.isContentSupported( askedContent

userProfile is an instance of UserProfile class which
cannot implement the Action abstract class. Still I
need any error in UserProfile#isContentSupported() to
be able to call something like processError() that in
turn can just suspend the execution of the state
machine by means of calling exactly as suggested in
[1] :
<transition event="" target="errorstate" />

I followed the code and it is not clear how I can
accomplish this ... Maybe instead of
SCXMLExecutor#triggerEvents we could add something
like  SCXMLExecutor#triggerException passing the name
of the internal event to be passed ( and
ensuring that that event can be the next step to be
done ignoring any other "standard" or "custom" action?

I have been calling my var assignments with the result
of my helper methods "custom actions" while I
understand they are not really "custom actions" from
scxml definitions so I rather use thye term once
suggested by Rahul I think "specific actions"

Any feedback here?, Thanks


--- Nestor Urquiza <> wrote:

> Hello guys,
> I guess because of my own mistake at some point I
> used:
> evts[0] = new TriggerEvent("app.error",    
>         TriggerEvent.ERROR_EVENT, null);
> to manage an error assumming that being the type =
> "ERROR" and having defined in my scxml:
> <n:transition event="app.error" target="IDDLE"/>
> the engine would go directly to IDDLE state and no
> other code would be executed from the scxml file.
> Going thru the code I see that this is wrong
> assumption since at least the last version of
> SCXMLExecutor#triggerEvents() restores the rest of
> the
> events data (restoreEventData(oldData);) and so the
> scxml continues executing the uneeded code.
> My question is ... is this a feature could/should be
> implemented? This is, when firing an error
> transition
> just ignore the rest of the actions to be executed
> and
> just execute the error event specified by
> TriggerEvent() constructor. If this is not an
> expected
> behavior from the SCXML specification I guess I can
> have the same behavior if I am able to call
> SCXMLExecutor#setEventData() to just clear the
> pending
> events, however this method is private. 
> Thanks as always for any help,
> Nestor
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message