One thing you may want to consider when tucking workflow data away
is the scope of the data. For example, if I jump out of the normal
workflow to do some object creation that will eventually be used by
the original workflow, the sub-workflow should probably not be able
to access the data of the original workflow other than what was
explicitly granted. This makes the contract between the outer workflow
and sub-workflow explicit and gives the subworkflow a place to play
with data without worrying about namespace-type collisions, etc..
It sort of works similar to a method in a way. A subworkflow has
specific values it takes as an initial environment (parameters of
sorts) and returns a set of values when finished (a multi-valued
return of sorts.)
This also creates a sort of scope stack. As each sub-workflow
completes, it's scoped data will be "freed". When the outermost
workflow completes, you'll know that all scoped data is gone. A
good way to avoid an ever-increasing session size.
I'm not sure how any of this would transfer to struts, but I thought
I'd poke my general workflow $0.02 in anyway.
-Paul Speed
P.S.: Sometimes its even possible to build scoping on top of a more
generalized workflow approach. If you imagine workflow as simply
a set of states and transitions between them, then you can attach
custom logic to the states. Essentially, the state is where you
currently are. To move to another state you execute a specific
transition that takes you to another state. This transition can
do all sorts of things, like push a new local environment and add
initialized values from the old local environment, ie: implement
a scope-based data model. In this kind of case, it's also preferable
to have some code associated with the transition that actually chooses
the next state. (Instead of always hard-coding that transitions always
point to another state.) That way you can support "returns" from
sub-workflows that take you back to the state you were in before
starting the sub-workflow. And it goes on from there, so I'll stop
now. ;)
Ted Husted wrote:
>
> Something I have found generally useful is a "Resource Cache". This is
> just a hashtable in the session where I can (judiciously) tuck objects
> for future reference. In the case of a multiform workflow, each of the
> subforms could be saved to the cache, and then recalled as needed along
> the way.
>
> Of course, you could do the same with the session alone, but some
> containers get testy if you put too many objects in the session, and
> this also gives you the opportunity to do some oversight management in
> terms of how much gets cached.
>
> I first started to use this in relation to a "foreign key" strategy for
> my ActionForms, where they automatically cache the value of a property
> that another table may use as a foreign key. New forms then check the
> cache to pre-populate their own foreign keys.
>
> I also have a strategy where a form can be saved to the cache (using a
> special submit button) to be completed later. If the actor visits
> another form that is related to the first, when they return to the first
> form, the relation (foreign key) is automatically inserted.
>
> This would work even better in an EJB, where sessions can be
> automatically saved, or under 2.3 where we can have session listeners
> that could serialize the cache before the session expires.
>
> This could also be a good place to tuck a workflow stack, should one be
> needed.
>
> "Robbin L. Gratz" wrote:
> >
> > Another point that I believe is getting ignored on the workflow stuff is how
> > is data getting transferred between the different steps. In the system I
> > just worked on, we had a number of two or more step workflows that were used
> > within other larger workflows. The output from these "sub workflows" needed
> > to be captured along the way to accomplish the parent workflow. My thought
> > was to have a controlling action whose associated data/form object stores
> > the data retrieved from the various steps of a workflow, whether these steps
> > were individual actions or another workflow process. Any thoughts from
> > anyone or has someone solved this issue more elegantly?
