commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <nest...@yahoo.com>
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="err.foo" 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 (err.fo) 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

[1]
http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114780510526564&w=2

--- Nestor Urquiza <nestoru@yahoo.com> 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 
> http://mail.yahoo.com 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message