David,
I agree with you: tokens should be used. See my previous postings as well
where I give reasons on why:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01330.html.
All these discussions about alternate scopes, workflow, custom context,
transaction token, command token, etc. are for me one and the same. It all
resolves in a context being identified by a token.
But I have not given further thoughts to this idea yet.
Fr.
-----Original Message-----
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 11 July 2001 00:33
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: ActionMapping Workflows
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/
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
