2011/5/12 Rahul Akolkar <rahul.akol...@gmail.com>
> On Thu, May 12, 2011 at 6:56 AM, Dario D <darac1...@gmail.com> wrote:
> > 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).
>
Thank you for your feedback, as always. In regards to the question and the
workflow example, let's suppose that a user has set the current state to B
after being in state D. Any local context which may have been created in
states C and D will remain associated to those states, until it gets
overwritten when the workflow transitions again to C and D, am I right?
To continue on the same workflow example, let's supposed that the worklow is
in state B. A bug in the workflow has been found at some later stage (states
C, D, E) and the user would like to correct this bug before continuing
execution of the workflow. Restarting the workflow is not a good idea
because actions executed in states A and B are too expensive to be repeated.
He corrects this bug and creates a new version of the worfklow model. The
application will then call the following method on the existing executor:
exec.setStateMachine(newWorkflowModel);
This effectively means that the above method would would've been called
twice on the executor (when the executor was first created before exec.go(),
and after the workflow has been corrected). Is this the right thing to do
and again, how would it affect the context which was made during
initialization of the worklow and in states A and B? If this is not a good
idea, can you suggest any alternatives?
