[scxml] Setting state through history element or other means

[Dario D <da...@gmail.com>]

Hello,

Is there a way to programatically change history state of a workflow? Our
idea is to be able to set freely the next state to be executed. If we set
the state like this:

        Set states = executor.getCurrentStatus().getStates();
        TransitionTarget tt = (TransitionTarget)
executor.getStateMachine().getTargets().get(stateId);
        states.clear();
        states.add(tt);

This will set current state, but "onentry" will not be executed, only
"onexit" on transition. Perhaps if we could somehow programatically change
current status of the executor, so that when we trigger an event that has
target="historyElement", the state machine will transition to the wanted
state. Is this possible?

Re: [scxml] Setting state through history element or other means

[Rahul Akolkar <ra...@gmail.com>]

On Wed, Sep 21, 2011 at 5:53 AM, Dario D <da...@gmail.com> wrote:
> Hello,
>
> Is there a way to programatically change history state of a workflow? Our
> idea is to be able to set freely the next state to be executed. If we set
> the state like this:
>
>        Set states = executor.getCurrentStatus().getStates();
>        TransitionTarget tt = (TransitionTarget)
> executor.getStateMachine().getTargets().get(stateId);
>        states.clear();
>        states.add(tt);
>
> This will set current state, but "onentry" will not be executed, only
> "onexit" on transition. Perhaps if we could somehow programatically change
> current status of the executor, so that when we trigger an event that has
> target="historyElement", the state machine will transition to the wanted
> state. Is this possible?
<snip/>

There is no straightforward way to programmatically manipulate
executor history. This is by design, as the historical record of
execution should be what it was. There are some usecases for
programmatic manipulation of current states (as can be done via
snippet above) such as pooling of executors or persist-resume
scenarios. Often, any need to do more programmatic manipulation beyond
that may be mitigated by rethinking the state machine and associated
events (including their payloads).

-Rahul

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