On Thu, May 12, 2011 at 6:56 AM, Dario D <darac1...@gmail.com> wrote:
> We're developing an application which will use SCXML for its workflow and I
> would ask you for advice on a couple of topics:
>
> 1) All workflows will have a single state which is called "error". Whenever
> a custom action catches an error, it will fire a derived event and this will
> cause the workflow go to the "error" state. Is it possible to expand this
> functionality to other execution errors? For example when an assignment is
> made to an undefined variable, or when an expression error happens, to fire
> an error event. I've tried making transitions that listen to "error.*" (
> http://www.w3.org/TR/scxml/#ErrorEvents) but they are not being used. I was
> also hoping to raise this event from ErrorReporter but we don't have a
> mechanism to raise events from there.
>
<snip/>
Your observations are correct, Commons SCXML v0.9 is not upto date
with respect to the latest spec changes. You may open an issue for
this, a patch will ensure its attended to sooner if you're so inclined
-- need to add the error event to the set of derived ones on catching
ExpressionException in SCXMLSemanticsImpl.
WRT approaches:
* An ErrorReporter implementation could be used, one that maintains a
reference to the SCXMLExecutor instance its attached to and fires
events asynchronously after a short delay
* Better yet, one could maintain an external event queue where
various components can add events (ErrorReporter being one) and these
get triggered in the order added
* Best fix is the semantics impl change along above lines
> 2) One requirement for the application is to allow setting an arbitrary
> state in a workflow. For example, if we have the following workflow:
>
> A->B->C->D->E
>
> and the workflow is currently in state D, a user should be able to move the
> workflow back to state B (or any other state). We were considering to use
> the following way (from the mailing list archives):
>
> public void setState(String state) {
> Set states = getCurrentStatus().getStates();
> TransitionTarget tt = getStateMachine().getTargets().get(state);
> states.clear();
> states.add(tt);
> }
>
> Would you recommend doing it this way and how would this affect on any
> context which was previously set?
<snap/>
It'd likely be OK with the drawback that it hides these transitions
from the SCXML document (so anyone staring at the document doesn't see
the whole picture). The above doesn't have any effect on the set
context(s).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
