Why not try enforcing some kind of composition. For instance, a workflow
might have 5 steps. Separate the components themselves from the order in
which they must be carried out. That is, if you must do 5 steps, then one
"WorkflowObject" will be composed of 5 "StepObject" s. Upon completion of
each step you will add the current step that you have completed to the
WorkflowObject and then tell the WorkflowObject to check to see if all five
steps have been added. If not, then send them to the next step. I think
this is nothing new, as Actions, ActionMappings, and ActionForms kind of
behave like this in a form wizard situation. However, maybe we can leverage
the same objects by making "WorkflowObject" and "StepObject" interfaces, and
make some of our homemade struts components implement these interfaces.
----- Original Message -----
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 4:04 PM
Subject: Re: ActionMapping Workflows
> 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/
>
