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
> > > > source.
> > > >
> > > > I'm also now thinking that, given a dynamic action path, the best
place
> > > > to represent it may be the ActionForward after all. This would
change
> > > > the struts-config in my last post to:
> > > >
> > > > <action ...>
> > > > <forward
> > > > name="continue"
> > > > path="/WEB-INF/pages/script/Form.jsp"
> > > > request="true"
> > > > actionPath="/script/Insert"/>
> > > > </action>
> > > >
> > > > which supports the idea of having an Action return various logical
> > > > forwards, which could map to various forms, and being able to
program
> > > > where those forms submit back to, all from within the
ActionMappings.
> > > >
> > > > Matthias Bauer wrote:
> > > >
> > > >>In the actions DisplayInsertAction or DisplayUpdateAction
respectively,
> >I store
> > > >>a state value in session scope which is checked in ProcessAction and
> >upon with I
> > > >>decide whether to do an update or insert.
> > > >>
> > > >>With this pattern I do not really see the necessity to dynamically
set
> >the
> > > >>action attribute in forms.
> > > >>
> > > >>Do I miss something?
> > > >>
> > > >>--- Matthias
> > > >>
> > > >>Ted Husted wrote:
> > > >>
> > > >>
> > > >>>The general idea I'm playing with now is
> > > >>>
> > > >>>1) Extend ActionMappings with "request" and "actionPath"
properties.
> > > >>>
> > > >>>2) Extend ActionServlet to place the ActionMapping in the request
> > > >>>context if request=true.
> > > >>>
> > > >>>3) Extend html:form to check for ActionMapping.getActionPath() when
the
> > > >>>path is not specified.
> > > >>>
> > > >>>So in struts-config you could specify
> > > >>>
> > > >>>request="true"
> > > >>>actionPath="/insertAction"
> > > >>>parameter="insert"
> > > >>>
> > > >>>or
> > > >>>
> > > >>>request="true"
> > > >>>actionPath="/updateAction"
> > > >>>parameter="update"
> > > >>>
> > > >>>and have the appropriate path automagically appear in your
html:form.
> > > >>>The Action can then call getParameter() to determine whether it's
> > > >>>suppose to insert or update the ActionForm data. Viola, no hidden
> > > >>>fields!
> > > >>>
> > >
> > >
> > >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
