First of all: Sounds good to restate the requirement.
Second: Maybe we can talk of some use cases here, in order to put some flesh to
the workflow bones.
How about considering the following really simple use case:
Workflow1: The user browses in an open community board and is currently visiting
Board xy and Thread yz. Now he wants to add a new comment to the thread. He
needs a valid account for that. As he does not yet have an account, he decides
to register himself. He ends up in starting Workflow2.
Workflow2: The user stept through the registration process, entering his
personal data and his desired username and password.
After Workflow2 has been finished he needs to return to Workflow1, i. e exactly
to the same position (Board xy and Thread yz) where he came from.
I don't know if this use case is appropriate. If not, pls come up with a better
or extended one. It surely is too trivial to cover all the aspects, but maybe it
helps to clarify at least the basic streamlines.
How do you all think the chain of action mappings should look like for this use
case and what happens regarding to the stack everybody talks of?
--- Matthias
Martin Cooper wrote:
> 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/
>>
>>
>
