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