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/
