What your thinking of may already do this, but I
thought I would mention this in case it didn't. If
you end up contructing a workflow using the actions,
it would be nice if it could be defined as a linked
list (or at least kept track of the last action). So
you wouldn't just go forward, but could be go back a
step too. This would be nice for multi-page forms
with a 'next' and 'previous' link so the JSP page
wouldn't have the links hardcoded.
David
--- Ted Husted <[EMAIL PROTECTED]> 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?
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
