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?
