Maybe the token that can be generated in an action be
used or make a workflow token.
David
--- "Robbin L. Gratz" <[EMAIL PROTECTED]>
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?
>
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 10, 2001 4:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ActionMapping Workflows
>
>
> I'm liking the ActionRequest idea. I've tried
> similar things, but needed
> the parameter map idea.
>
> Do you have any code yet?
>
> I agree that leveraging ActionForwards sounds like
> the way to go.
>
> As to the requirements Matthias started, I would
> change 3 to
>
> 3. The ability to call (or nest) another workflow
> and return to the
> current step when the called workflow is complete.
>
> So as to not imply a particular implementation.
>
> Martin Cooper wrote:
> >
> > I have a similar concern. In addition, there may
> be runtime parameter
> > values that need to be passed along, particularly
> when actions are chained
> > (something I do a lot of).
> >
> > I am working on something related, in conjunction
> with what Matthias
> > referred to as a return stack. The goal is to be
> able to handle "go back
> to
> > where you came from" requests, where the
> specification of the actual
> > destination could require multiple dynamic
> parameters.
> >
> > The idea is that there is something called an
> ActionRequest, which is
> > essentially a combination of an ActionForward and
> a parameter Map, with
> > some "smarts" added in. A stack of these objects
> is kept in the session.
> > When one is popped off the stack, the "smarts"
> will find the appropriate
> > form bean type, populate one from the parameter
> map, forward the request
> as
> > appropriate, and have Struts invoke the target
> action with this new form
> > bean instead of the one it would normally get.
> >
> > I haven't fully figured this out yet, and there
> are some pieces of the
> > puzzle I'm still working through. It's pretty
> clearly targetted at using
> > forwards to chain actions, but it should be able
> to be extended to work
> > with redirects, forwards to JSPs, etc.
> >
> > Thoughts, anyone?
> >
> > --
> > Martin Cooper
> >
> > At 08:35 AM 7/10/01, 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?
> > >
> > >-----Original Message-----
> > >From: Jonathan [mailto:[EMAIL PROTECTED]]
> > >Sent: Tuesday, July 10, 2001 8:35 AM
> > >To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> > >Subject: Re: ActionMapping Workflows
> > >
> > >
> > >Can I ask how you all are thinking about bouncing
> around between steps in
> > >the workflow? Is it a stack that each step gets
> popped off? Arent
> workflow
> > >steps cyclical sometimes? Developers talk alot
> about graphing workflows
> but
> > >I have not read about the implementation.
> > >
> > >
> > >----- Original Message -----
> > >From: "Matthias Bauer"
> <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: Tuesday, July 10, 2001 9:12 AM
> > >Subject: Re: ActionMapping Workflows
> > >
> > >
> > > > Ok, that's fine with me and it makes pretty
> much sense. However, this
> will
> > >not
> > > > be enough to implement workflow completely. It
> is just a little step
> > >toward
> > > > workflow control as a whole, just the same as
> the simple workflow
> > >extension I
> > > > already proposed together with some code on
> this list.
> > > >
> > > > I think all this should be put together to
> come up with a reasonable
> > >concept how
> > > > to implement workflow, instead of multiple
> single efforts to implement
> > >some
> > > > single aspects only.
> > > >
> > > > Is there a team working on that?
> > > >
> > > > --- Matthias
> > > >
> > > >
> > > >
> > > > Ted Husted wrote:
> > > >
> > > > > I suppose storing the information in the
> session would work. Though,
> I
> > > > > imagine this means the state value would be
> hardcoded into the Java
> > > > > source. I'm working toward scripting
> workflows from within the
> > > > > ActionMappings, and would like to be able to
> reroute the flow
> without
> > > > > changing the Java source.
> > > > >
> > > > > The insert/update flow is one example.
> Another would be inserting
> one
> > > > > record and stopping, or inserting one record
> type and then another
> type
> > > > > (and another type). Like say, creating a new
> vendor account, and
> then a
> > > > > contact record for the account, and then a
> new stock item for the
> > > > > account. With a dynamic action path, you can
> script something like
> this
> > > > > from the ActionMappings alone, without
> modifying the JSPs or Java
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
