Right now, what I have is a combination of code fragments, pseudo-code, and
stuff that's still in my head. I expect to turn this into real code in the
next day or so.
Point taken regarding not implying an implementation. I agree with your
restatement of the real requirement. My near-term implementation may still
be a stack, though. :-}
--
Martin Cooper
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 2:16 PM
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/
>
