I agree that the idea of lock-step stack doesn't seem to fit well within
a Web application.
A more useful idea might be a cursor that tracked the farthest step
reached. The entry point of the workflow (step 1) could "fast-forward"
if a cursor for that workflow was present. The cursor might be one of
the "ActionRequest" objects that Martin suggested. In effect, each step
of the workflow would be setting a bookmark, so the actor can be
returned to whereever they left off if the workflow were re-entered.
If the workflow needs to branch, then the branch might store that same
cursor at its tail somehow, so when the workflow completed, "success" at
the last step could bring it back to the calling workflow (rather than a
menu).
With dynamic action paths, each step of the workflow would be able to
set a form to submit back to one it's own mappings, and keep the chain
intact.
With a resource cache, the workflow would have a place to store
temporary data until the workflow completes, at which point the final
step could remove any workflow objects from the cache.
"Robbin L. Gratz" wrote:
>
> With the "return stack" concept, I'm assuming this will be a session scope
> variable. What happens when the user clicks the back button rather than
> going through the process the app provides? Now the session is out of synch
> with the actual position in the process that the user is in. It seems to me
> that there has to be some sort of request/page scope data item in the form
> of a hidden variable or link parameter that indicates what position in the
> process the user is in. I had thought about the stack concept before but
> couldn't get past this problem. Has anyone else come up with a solution?
