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!
> > >>>
> >
> >
> >
