You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Adam L <ad...@hotmail.com> on 2003/09/28 04:27:19 UTC
Re:[PARTLY SOLVED] workflow - Re: integration with other app
Okay.. the back button going to the prior screen.. you'd think i've never
done webapps before.. my no-cache headers were missing. that's resolved.
I've begun to grok the workflow pattern a bit more, and here's what i've
come up with
I was picturing the overall task as a workflow. However, if you look at
each discrete unit of work in the entire task, each unit is actually its own
workflow. And, the pieces/steps of that unit are what you should use to
define individual "workflows" in the sense of the extension.
Ergo, task 1 has steps 1, 2 and 3. which gives you workflow1, workflow2,
and workflow3.
each workflow<n> should likely have 2 steps: display the page (enter
the workflow), and submit data from that page (end of workflow). along with
these 2 steps, there is also a possible workflow violation, which, ideally,
should flow you to the 'display the page' step. Each end(termination) of a
workflow's primary flow will lead into the next step's 2ndary workflow
chain.
granted, this is a very simplistic overview, and not applicable for all
tasks.. but, it's a nice foundation step that wasn't readily obvious in the
documentation (or I was just being horribly dense).
So, have I grokked this properly ? Is there something else I"m missing?
-- adam
----- Original Message -----
From: "Adam L" <ad...@hotmail.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Saturday, September 27, 2003 2:58 PM
Subject: Re: workflow - Re: integration with other app
> Matthias:
>
> I've been dinking with this workflow extension for awhile, amidst other
> madness, and here's what I've come to observe. Please let me know if my
> observations are correct, and if there's not a "better/easier" way to
> achieve my goals:
>
> I have a logical process flow for achieving the task of entering new
> data. This requires 7 different screens on input information, as each
> subsequent entry page requires info from the prior. I originally
defined
> this as one primary "workflow". Everything flows from one page to the
next,
> so long as I don't use the browser back button and change prior
information.
> If I do this (hit browser back, change a form field, submit), the next
> page ends up blank; granted, I haven't added any "back button" links to
the
> page. This is obviously due to a workflow violation exception being
thrown.
> That's fine. However, in order for the workflow engine to redirect the
> user to the proper page, it appears i'm going to have to break down my
one
> workflow into 7 individual "workflows", each leading to eachother using
> primary and secondary flows, and then adding in a global foward for a
> violation for each one of those new 7 segments. Is this correct? It
seems
> like a lot of work for a simple process, and I'm afraid I'm missing
> something.
>
> Also, back to the browser back button. In running the demo, I can see
> that hitting the browser back from wizard page 2 will continually redirect
> me back to wizard page 2. yet, in my application, hitting the back button
> just takes me to the prior screen. Is this a result of not having the
> violation logic in place? If so, why isn't there a blank screen like I
> described above?
>
> Thank you for any insight you can provide.
>
> -- adam
>
>
> ----- Original Message -----
> From: "Matthias Bauer" <ma...@livinglogic.de>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> Sent: Monday, September 15, 2003 1:59 AM
> Subject: Re: workflow - Re: integration with other app
>
>
> > Fortunately I am far enough away to avoid your kiss ;-)
> >
> > Please let me know, if you believe something is missing. I am sure I can
> > give you some more hints on how to solve a specific task. The Struts
> > Workflow Extension is a very powerful, yet low-level framework. Thus, it
> > offers very much flexibility but sometimes the right way to achieve a
> > solution is not as apparent as desired.
> >
> > Just in case you are interested: We are also offering commercial support
> > for this extension and Struts itself.
> >
> > --- Matthias
> >
> >
> > Adam Levine wrote:
> >
> > > Matthias:
> > > I could kiss you! I've been struggling with this issue and have
> > > been going bald over the last week doing a lot of my own engine
> > > work. I can't wait to try this out and see if it doesn't work for me
> > > as cleanly as it looks.
> > >
> > >
> > >
> > >
> > > From: Matthias Bauer <ma...@livinglogic.de>
> > > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > > Subject: Re: workflow - Re: integration with other app
> > > Date: Fri, 12 Sep 2003 08:35:36 +0200
> > >
> > > Martin,
> > >
> > > the Struts Workflow Extension http://www.livinglogic.de/Struts/
> > > addresses some of the issues you raise. Especially the thing about a
> > > workflow scope. But it is also easily possible to build reusable
> > > action sequences: Consider for instance a confirmation dialog that
> > > demands the user to press a "Yes" and "No" button. You will need this
> > > multiple times within an application, but you normally want to code
> > > the necessary actions only once and reuse them in different contexts
> > > (i. e. with a customized question and return action).
> > >
> > > Please let me know, when you have any questions related to the Struts
> > > Workflow Extension.
> > >
> > > --- Matthias
> > >
> > > Martin Naskovski wrote:
> > >
> > >> One thing I find particularly cumbersome in Struts is web page
> > >> workflow. Currently, if I want to push "Cancel" for instance, or
> > >> "Submit" on a certain page, in the Action itself, I have to hard code
> > >> where to go next and/or pass any dynamically generated parameters
> > >> through the request scope or the query string (if doing a
> > >> sendRedirect). I also have to use hidden form fields to tell each
> > >> submission button on a form, where to go next, depending on where I
> > >> came from (a certain action mapping, e.g.).
> > >>
> > >> Is there a better way to do this, where the flow of the screens can
be
> > >> specified statically, or maybe if not statically at least within a
> > >> screen workflow module that each action will tell that module where
> > >> to go next, depending on what button was pushed on that form?
> > >>
> > >> Does JSF address this perhaps? Or has someone independently made a
> > >> Struts pluggable module that can control screen flow? It seems there
> > >> almost is a need for some sort of a 'workflow' scope, where when I
> > >> start a certain use-case from one of the menus in the application,
the
> > >> 'workflow scope' is preserved throughout the use-case lifetime, and
if
> > >> for some reason this flow is broken by the user, the workflow scope
> > >> should be destroyed.
> > >>
> > >> I've been able to immitate a workflow scope with the session scope,
> > >> but it isn't as elegant as I want it to be, or rather, as delimited
> > >> from the application logic as I'd like it to be... Plus stuff in the
> > >> session scope hangs around much longer than as if I had a workflow
> > >> scope.
> > >>
> > >> I've been wondering if there's any solutions already to this - it
> > >> seems that is the _only_ thing Struts is lacking in.
> > >>
> > >> Thanks.
> > >>
> > >> Martin
> > >> --
> > >>
> > >>
> > >> Thursday, September 11, 2003, 4:31:29 PM, you wrote:
> > >>
> > >> TH> This seems more in scope for some of the ServerSide forums than
> > >> Struts.
> > >>
> > >> TH> http://www.theserverside.com/home/index.jsp
> > >>
> > >> TH> Our framework ends where the database begins -:0)
> > >>
> > >> TH> Tiles is sufficient for customizating layout and such.
> > >>
> > >> TH> -Ted.
> > >>
> > >> TH> Gregory Seidman wrote:
> > >>
> > >> TH> <snip/>
> > >>
> > >>
> > >>
> > >>>> My purpose in posting this to the list is to get the benefit of the
> > >>>> membership's collective experience. Is Torque a good choice? Is
> > >>>> creating a
> > >>>> separate database for each user unacceptable from the point of view
> > >>>> of a
> > >>>> website which provides services on a per-user basis? Is Tiles
> > >>>> sufficient
> > >>>> for customizing layout and such? Any suggestions, tales of woe, or
> > >>>> design
> > >>>> critiques are appreciated.
> > >>>>
> > >>>> Please do not CC me; I am subscribed to the list.
> > >>>> --Greg
> > >>>>
> > >>>>
> >
>>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > >>>> For additional commands, e-mail:
> > >>>> struts-user-help@jakarta.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> > > _________________________________________________________________
> > > Get a FREE computer virus scan online from McAfee.
> > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: workflow extension question
Posted by Matthias Bauer <ma...@livinglogic.de>.
Adam,
there is a solution to your requirement. If I get you right, here is
what you want to do: You are in a modal dialog. If the user clicks on
some link he violates the workflow. The action that violates the
workflow should check whether this is a nextState violation. Upon
nextState violation you end all relevant workflows and forward to the
action that caused the workflow violation.
Here is how you can check whether it is a nextState violation: There is
an action contained in the workflow package that can easily be used for
this: ForwardNextStateViolationAction. Use this class in the action that
handles workflow violations. It chooses the forward
"noNextStateViolation", if there was no nextState violation encountered
(i. e. it must have been a prevState violation). If a nextState
violation was encountered it forwards to the path that caused this
workflow violation (this can be an arbitrary action choosen from your
menu). Have a look at the action's code: It uses the method
WorkflowUtils.getNextStateViolationAction that provides the required
information.
Hope this additional info helps.
--- Matthias
Adam L wrote:
>Matthias:
> Now to take you up on your offer. "is something missing?"
>
> What thoughts do you have on a "end all previous workflows" property?
>The thought is this:
> - my user is working through a process, and gets bored or distracted
> - rather than using the provided "cancel" button, they use a nav link
>to go elsewhere (ie, a terms and conditions or "what's new page")
> - my thought is to let them do this, perhaps they'll jump back
>(browser back) to the step they were on and continue their path
> - but, if they don't ever come back, and end up starting another
>workflow process, they'll be dumped right back to their first workflow.
> - being thrown back to a place you wanted to leave would be confusing
>
> So, the answer to this is an "initialization" page for each process
>that basically says "cancel out all existing workflows and states, and start
>this workflow instead".
>
> Yes, ideally, the user should use the opt-out mechanism provided
>to them, but you can't expect that to happen. And, I'm not keen on designing
>for a modal experience unless absolutely necessary. One could go through
>every possible action and add a "noWorkflowChecks" everywhere, but that
>still doesn't resolve the issue of them starting a new process w/o
>explicitly terminating an existing one.
>
> To illustrate what I'm seeing:
>
><!-- the landing page for initializing this process -->
><action
> path="/content/startNewTask"
> forward="/content/displayTaskStartScreen.do">
> <set-property property="authClass"
>value="com.foo.workflow.authentication.LoggedInAuthentication" />
> <set-property property="endAllExistingWorkflows" value="true">
><------------ new property
> <set-property property="primaryWorkflow" value="wkfAddNewTraitStart"/>
> <set-property property="newState" value="initialized"/>
> <!-- not logged in authentication exception -->
> <forward name="authenticationException" path="/login.jsp" />
></action>
>
>
>Any thoughts?
>
>-- adam
>
>
>
>>>>----- Original Message -----
>>>>From: "Matthias Bauer" <ma...@livinglogic.de>
>>>>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>>>Sent: Monday, September 15, 2003 1:59 AM
>>>>Subject: Re: workflow - Re: integration with other app
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Fortunately I am far enough away to avoid your kiss ;-)
>>>>>
>>>>>Please let me know, if you believe something is missing. I am sure I
>>>>>
>>>>>
>can
>
>
>>>>>give you some more hints on how to solve a specific task. The Struts
>>>>>Workflow Extension is a very powerful, yet low-level framework. Thus,
>>>>>
>>>>>
>it
>
>
>>>>>offers very much flexibility but sometimes the right way to achieve a
>>>>>solution is not as apparent as desired.
>>>>>
>>>>>Just in case you are interested: We are also offering commercial
>>>>>
>>>>>
>support
>
>
>>>>>for this extension and Struts itself.
>>>>>
>>>>>--- Matthias
>>>>>
>>>>>
>>>>>Adam Levine wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Matthias:
>>>>>>I could kiss you! I've been struggling with this issue and have
>>>>>>been going bald over the last week doing a lot of my own engine
>>>>>>work. I can't wait to try this out and see if it doesn't work for me
>>>>>>as cleanly as it looks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>From: Matthias Bauer <ma...@livinglogic.de>
>>>>>>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
>>>>>>To: Struts Users Mailing List <st...@jakarta.apache.org>
>>>>>>Subject: Re: workflow - Re: integration with other app
>>>>>>Date: Fri, 12 Sep 2003 08:35:36 +0200
>>>>>>
>>>>>>Martin,
>>>>>>
>>>>>>the Struts Workflow Extension http://www.livinglogic.de/Struts/
>>>>>>addresses some of the issues you raise. Especially the thing about a
>>>>>>workflow scope. But it is also easily possible to build reusable
>>>>>>action sequences: Consider for instance a confirmation dialog that
>>>>>>demands the user to press a "Yes" and "No" button. You will need this
>>>>>>multiple times within an application, but you normally want to code
>>>>>>the necessary actions only once and reuse them in different contexts
>>>>>>(i. e. with a customized question and return action).
>>>>>>
>>>>>>Please let me know, when you have any questions related to the Struts
>>>>>>Workflow Extension.
>>>>>>
>>>>>>--- Matthias
>>>>>>
>>>>>>Martin Naskovski wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>One thing I find particularly cumbersome in Struts is web page
>>>>>>>workflow. Currently, if I want to push "Cancel" for instance, or
>>>>>>>"Submit" on a certain page, in the Action itself, I have to hard code
>>>>>>>where to go next and/or pass any dynamically generated parameters
>>>>>>>through the request scope or the query string (if doing a
>>>>>>>sendRedirect). I also have to use hidden form fields to tell each
>>>>>>>submission button on a form, where to go next, depending on where I
>>>>>>>came from (a certain action mapping, e.g.).
>>>>>>>
>>>>>>>Is there a better way to do this, where the flow of the screens can
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>be
>>>
>>>
>>>
>>>
>>>>>>>specified statically, or maybe if not statically at least within a
>>>>>>>screen workflow module that each action will tell that module where
>>>>>>>to go next, depending on what button was pushed on that form?
>>>>>>>
>>>>>>>Does JSF address this perhaps? Or has someone independently made a
>>>>>>>Struts pluggable module that can control screen flow? It seems there
>>>>>>>almost is a need for some sort of a 'workflow' scope, where when I
>>>>>>>start a certain use-case from one of the menus in the application,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>the
>>>
>>>
>>>
>>>
>>>>>>>'workflow scope' is preserved throughout the use-case lifetime, and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>if
>>>
>>>
>>>
>>>
>>>>>>>for some reason this flow is broken by the user, the workflow scope
>>>>>>>should be destroyed.
>>>>>>>
>>>>>>>I've been able to immitate a workflow scope with the session scope,
>>>>>>>but it isn't as elegant as I want it to be, or rather, as delimited
>>>>>>>
>>>>>>>
>>>>>>>from the application logic as I'd like it to be... Plus stuff in the
>>>>>>
>>>>>>
>>>>>>>session scope hangs around much longer than as if I had a workflow
>>>>>>>scope.
>>>>>>>
>>>>>>>I've been wondering if there's any solutions already to this - it
>>>>>>>seems that is the _only_ thing Struts is lacking in.
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>Martin
>>>>>>>--
>>>>>>>
>>>>>>>
>>>>>>>Thursday, September 11, 2003, 4:31:29 PM, you wrote:
>>>>>>>
>>>>>>>TH> This seems more in scope for some of the ServerSide forums than
>>>>>>>Struts.
>>>>>>>
>>>>>>>TH> http://www.theserverside.com/home/index.jsp
>>>>>>>
>>>>>>>TH> Our framework ends where the database begins -:0)
>>>>>>>
>>>>>>>TH> Tiles is sufficient for customizating layout and such.
>>>>>>>
>>>>>>>TH> -Ted.
>>>>>>>
>>>>>>>TH> Gregory Seidman wrote:
>>>>>>>
>>>>>>>TH> <snip/>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>My purpose in posting this to the list is to get the benefit of the
>>>>>>>>>membership's collective experience. Is Torque a good choice? Is
>>>>>>>>>creating a
>>>>>>>>>separate database for each user unacceptable from the point of view
>>>>>>>>>of a
>>>>>>>>>website which provides services on a per-user basis? Is Tiles
>>>>>>>>>sufficient
>>>>>>>>>for customizing layout and such? Any suggestions, tales of woe, or
>>>>>>>>>design
>>>>>>>>>critiques are appreciated.
>>>>>>>>>
>>>>>>>>>Please do not CC me; I am subscribed to the list.
>>>>>>>>>--Greg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>>>For additional commands, e-mail:
>>>>>>>>>struts-user-help@jakarta.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>
>>>>>>_________________________________________________________________
>>>>>>Get a FREE computer virus scan online from McAfee.
>>>>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
workflow extension question
Posted by Adam L <ad...@hotmail.com>.
Matthias:
Now to take you up on your offer. "is something missing?"
What thoughts do you have on a "end all previous workflows" property?
The thought is this:
- my user is working through a process, and gets bored or distracted
- rather than using the provided "cancel" button, they use a nav link
to go elsewhere (ie, a terms and conditions or "what's new page")
- my thought is to let them do this, perhaps they'll jump back
(browser back) to the step they were on and continue their path
- but, if they don't ever come back, and end up starting another
workflow process, they'll be dumped right back to their first workflow.
- being thrown back to a place you wanted to leave would be confusing
So, the answer to this is an "initialization" page for each process
that basically says "cancel out all existing workflows and states, and start
this workflow instead".
Yes, ideally, the user should use the opt-out mechanism provided
to them, but you can't expect that to happen. And, I'm not keen on designing
for a modal experience unless absolutely necessary. One could go through
every possible action and add a "noWorkflowChecks" everywhere, but that
still doesn't resolve the issue of them starting a new process w/o
explicitly terminating an existing one.
To illustrate what I'm seeing:
<!-- the landing page for initializing this process -->
<action
path="/content/startNewTask"
forward="/content/displayTaskStartScreen.do">
<set-property property="authClass"
value="com.foo.workflow.authentication.LoggedInAuthentication" />
<set-property property="endAllExistingWorkflows" value="true">
<------------ new property
<set-property property="primaryWorkflow" value="wkfAddNewTraitStart"/>
<set-property property="newState" value="initialized"/>
<!-- not logged in authentication exception -->
<forward name="authenticationException" path="/login.jsp" />
</action>
Any thoughts?
-- adam
> >>----- Original Message -----
> >>From: "Matthias Bauer" <ma...@livinglogic.de>
> >>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> >>Sent: Monday, September 15, 2003 1:59 AM
> >>Subject: Re: workflow - Re: integration with other app
> >>
> >>
> >>
> >>
> >>>Fortunately I am far enough away to avoid your kiss ;-)
> >>>
> >>>Please let me know, if you believe something is missing. I am sure I
can
> >>>give you some more hints on how to solve a specific task. The Struts
> >>>Workflow Extension is a very powerful, yet low-level framework. Thus,
it
> >>>offers very much flexibility but sometimes the right way to achieve a
> >>>solution is not as apparent as desired.
> >>>
> >>>Just in case you are interested: We are also offering commercial
support
> >>>for this extension and Struts itself.
> >>>
> >>>--- Matthias
> >>>
> >>>
> >>>Adam Levine wrote:
> >>>
> >>>
> >>>
> >>>>Matthias:
> >>>> I could kiss you! I've been struggling with this issue and have
> >>>>been going bald over the last week doing a lot of my own engine
> >>>>work. I can't wait to try this out and see if it doesn't work for me
> >>>>as cleanly as it looks.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>From: Matthias Bauer <ma...@livinglogic.de>
> >>>>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> >>>>To: Struts Users Mailing List <st...@jakarta.apache.org>
> >>>>Subject: Re: workflow - Re: integration with other app
> >>>>Date: Fri, 12 Sep 2003 08:35:36 +0200
> >>>>
> >>>>Martin,
> >>>>
> >>>>the Struts Workflow Extension http://www.livinglogic.de/Struts/
> >>>>addresses some of the issues you raise. Especially the thing about a
> >>>>workflow scope. But it is also easily possible to build reusable
> >>>>action sequences: Consider for instance a confirmation dialog that
> >>>>demands the user to press a "Yes" and "No" button. You will need this
> >>>>multiple times within an application, but you normally want to code
> >>>>the necessary actions only once and reuse them in different contexts
> >>>>(i. e. with a customized question and return action).
> >>>>
> >>>>Please let me know, when you have any questions related to the Struts
> >>>>Workflow Extension.
> >>>>
> >>>>--- Matthias
> >>>>
> >>>>Martin Naskovski wrote:
> >>>>
> >>>>
> >>>>
> >>>>>One thing I find particularly cumbersome in Struts is web page
> >>>>>workflow. Currently, if I want to push "Cancel" for instance, or
> >>>>>"Submit" on a certain page, in the Action itself, I have to hard code
> >>>>>where to go next and/or pass any dynamically generated parameters
> >>>>>through the request scope or the query string (if doing a
> >>>>>sendRedirect). I also have to use hidden form fields to tell each
> >>>>>submission button on a form, where to go next, depending on where I
> >>>>>came from (a certain action mapping, e.g.).
> >>>>>
> >>>>>Is there a better way to do this, where the flow of the screens can
> >>>>>
> >>>>>
> >be
> >
> >
> >>>>>specified statically, or maybe if not statically at least within a
> >>>>>screen workflow module that each action will tell that module where
> >>>>>to go next, depending on what button was pushed on that form?
> >>>>>
> >>>>>Does JSF address this perhaps? Or has someone independently made a
> >>>>>Struts pluggable module that can control screen flow? It seems there
> >>>>>almost is a need for some sort of a 'workflow' scope, where when I
> >>>>>start a certain use-case from one of the menus in the application,
> >>>>>
> >>>>>
> >the
> >
> >
> >>>>>'workflow scope' is preserved throughout the use-case lifetime, and
> >>>>>
> >>>>>
> >if
> >
> >
> >>>>>for some reason this flow is broken by the user, the workflow scope
> >>>>>should be destroyed.
> >>>>>
> >>>>>I've been able to immitate a workflow scope with the session scope,
> >>>>>but it isn't as elegant as I want it to be, or rather, as delimited
> >>>>>from the application logic as I'd like it to be... Plus stuff in the
> >>>>>session scope hangs around much longer than as if I had a workflow
> >>>>>scope.
> >>>>>
> >>>>>I've been wondering if there's any solutions already to this - it
> >>>>>seems that is the _only_ thing Struts is lacking in.
> >>>>>
> >>>>>Thanks.
> >>>>>
> >>>>>Martin
> >>>>>--
> >>>>>
> >>>>>
> >>>>>Thursday, September 11, 2003, 4:31:29 PM, you wrote:
> >>>>>
> >>>>>TH> This seems more in scope for some of the ServerSide forums than
> >>>>>Struts.
> >>>>>
> >>>>>TH> http://www.theserverside.com/home/index.jsp
> >>>>>
> >>>>>TH> Our framework ends where the database begins -:0)
> >>>>>
> >>>>>TH> Tiles is sufficient for customizating layout and such.
> >>>>>
> >>>>>TH> -Ted.
> >>>>>
> >>>>>TH> Gregory Seidman wrote:
> >>>>>
> >>>>>TH> <snip/>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>My purpose in posting this to the list is to get the benefit of the
> >>>>>>>membership's collective experience. Is Torque a good choice? Is
> >>>>>>>creating a
> >>>>>>>separate database for each user unacceptable from the point of view
> >>>>>>>of a
> >>>>>>>website which provides services on a per-user basis? Is Tiles
> >>>>>>>sufficient
> >>>>>>>for customizing layout and such? Any suggestions, tales of woe, or
> >>>>>>>design
> >>>>>>>critiques are appreciated.
> >>>>>>>
> >>>>>>>Please do not CC me; I am subscribed to the list.
> >>>>>>>--Greg
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>>>>>For additional commands, e-mail:
> >>>>>>>struts-user-help@jakarta.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>>>
> >>>>_________________________________________________________________
> >>>>Get a FREE computer virus scan online from McAfee.
> >>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [PARTLY SOLVED] workflow - Re: integration with other app
Posted by Matthias Bauer <ma...@livinglogic.de>.
Adam,
I'm glad, I read this mail before answering your preceding one :-)
You are right with everything you are saying. The term workflow might be
a little bit confusing in a scenario like yours. The natural approach
would be to define a single workflow for the whole sequence of steps.
But due to the fact that the Struts Workflow Extension only allows to
handle workflow violations on a per workflow case, you are forced to
define single workflows for each single step. I already considered
changing this, but did not, because as soon as you have got this idea
the mechanism works very well.
I hoped that the demo application that copes with a similar case (made
up of 3 steps), would clarify this for everybody. Looks like this is not
entirely true. Even though you figured it out in the end, it seems like
you had a pretty hard time. I will try to clarify this in future.
--- Matthias
Adam L wrote:
>Okay.. the back button going to the prior screen.. you'd think i've never
>done webapps before.. my no-cache headers were missing. that's resolved.
>
>I've begun to grok the workflow pattern a bit more, and here's what i've
>come up with
>
> I was picturing the overall task as a workflow. However, if you look at
>each discrete unit of work in the entire task, each unit is actually its own
>workflow. And, the pieces/steps of that unit are what you should use to
>define individual "workflows" in the sense of the extension.
> Ergo, task 1 has steps 1, 2 and 3. which gives you workflow1, workflow2,
>and workflow3.
> each workflow<n> should likely have 2 steps: display the page (enter
>the workflow), and submit data from that page (end of workflow). along with
>these 2 steps, there is also a possible workflow violation, which, ideally,
>should flow you to the 'display the page' step. Each end(termination) of a
>workflow's primary flow will lead into the next step's 2ndary workflow
>chain.
>
> granted, this is a very simplistic overview, and not applicable for all
>tasks.. but, it's a nice foundation step that wasn't readily obvious in the
>documentation (or I was just being horribly dense).
>
> So, have I grokked this properly ? Is there something else I"m missing?
>
>-- adam
>
>
>
>----- Original Message -----
>From: "Adam L" <ad...@hotmail.com>
>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>Sent: Saturday, September 27, 2003 2:58 PM
>Subject: Re: workflow - Re: integration with other app
>
>
>
>
>>Matthias:
>>
>> I've been dinking with this workflow extension for awhile, amidst other
>>madness, and here's what I've come to observe. Please let me know if my
>>observations are correct, and if there's not a "better/easier" way to
>>achieve my goals:
>>
>> I have a logical process flow for achieving the task of entering new
>>data. This requires 7 different screens on input information, as each
>>subsequent entry page requires info from the prior. I originally
>>
>>
>defined
>
>
>>this as one primary "workflow". Everything flows from one page to the
>>
>>
>next,
>
>
>>so long as I don't use the browser back button and change prior
>>
>>
>information.
>
>
>>If I do this (hit browser back, change a form field, submit), the next
>>page ends up blank; granted, I haven't added any "back button" links to
>>
>>
>the
>
>
>>page. This is obviously due to a workflow violation exception being
>>
>>
>thrown.
>
>
>>That's fine. However, in order for the workflow engine to redirect the
>>user to the proper page, it appears i'm going to have to break down my
>>
>>
>one
>
>
>>workflow into 7 individual "workflows", each leading to eachother using
>>primary and secondary flows, and then adding in a global foward for a
>>violation for each one of those new 7 segments. Is this correct? It
>>
>>
>seems
>
>
>>like a lot of work for a simple process, and I'm afraid I'm missing
>>something.
>>
>> Also, back to the browser back button. In running the demo, I can see
>>that hitting the browser back from wizard page 2 will continually redirect
>>me back to wizard page 2. yet, in my application, hitting the back button
>>just takes me to the prior screen. Is this a result of not having the
>>violation logic in place? If so, why isn't there a blank screen like I
>>described above?
>>
>> Thank you for any insight you can provide.
>>
>>-- adam
>>
>>
>>----- Original Message -----
>>From: "Matthias Bauer" <ma...@livinglogic.de>
>>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>Sent: Monday, September 15, 2003 1:59 AM
>>Subject: Re: workflow - Re: integration with other app
>>
>>
>>
>>
>>>Fortunately I am far enough away to avoid your kiss ;-)
>>>
>>>Please let me know, if you believe something is missing. I am sure I can
>>>give you some more hints on how to solve a specific task. The Struts
>>>Workflow Extension is a very powerful, yet low-level framework. Thus, it
>>>offers very much flexibility but sometimes the right way to achieve a
>>>solution is not as apparent as desired.
>>>
>>>Just in case you are interested: We are also offering commercial support
>>>for this extension and Struts itself.
>>>
>>>--- Matthias
>>>
>>>
>>>Adam Levine wrote:
>>>
>>>
>>>
>>>>Matthias:
>>>> I could kiss you! I've been struggling with this issue and have
>>>>been going bald over the last week doing a lot of my own engine
>>>>work. I can't wait to try this out and see if it doesn't work for me
>>>>as cleanly as it looks.
>>>>
>>>>
>>>>
>>>>
>>>>From: Matthias Bauer <ma...@livinglogic.de>
>>>>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
>>>>To: Struts Users Mailing List <st...@jakarta.apache.org>
>>>>Subject: Re: workflow - Re: integration with other app
>>>>Date: Fri, 12 Sep 2003 08:35:36 +0200
>>>>
>>>>Martin,
>>>>
>>>>the Struts Workflow Extension http://www.livinglogic.de/Struts/
>>>>addresses some of the issues you raise. Especially the thing about a
>>>>workflow scope. But it is also easily possible to build reusable
>>>>action sequences: Consider for instance a confirmation dialog that
>>>>demands the user to press a "Yes" and "No" button. You will need this
>>>>multiple times within an application, but you normally want to code
>>>>the necessary actions only once and reuse them in different contexts
>>>>(i. e. with a customized question and return action).
>>>>
>>>>Please let me know, when you have any questions related to the Struts
>>>>Workflow Extension.
>>>>
>>>>--- Matthias
>>>>
>>>>Martin Naskovski wrote:
>>>>
>>>>
>>>>
>>>>>One thing I find particularly cumbersome in Struts is web page
>>>>>workflow. Currently, if I want to push "Cancel" for instance, or
>>>>>"Submit" on a certain page, in the Action itself, I have to hard code
>>>>>where to go next and/or pass any dynamically generated parameters
>>>>>through the request scope or the query string (if doing a
>>>>>sendRedirect). I also have to use hidden form fields to tell each
>>>>>submission button on a form, where to go next, depending on where I
>>>>>came from (a certain action mapping, e.g.).
>>>>>
>>>>>Is there a better way to do this, where the flow of the screens can
>>>>>
>>>>>
>be
>
>
>>>>>specified statically, or maybe if not statically at least within a
>>>>>screen workflow module that each action will tell that module where
>>>>>to go next, depending on what button was pushed on that form?
>>>>>
>>>>>Does JSF address this perhaps? Or has someone independently made a
>>>>>Struts pluggable module that can control screen flow? It seems there
>>>>>almost is a need for some sort of a 'workflow' scope, where when I
>>>>>start a certain use-case from one of the menus in the application,
>>>>>
>>>>>
>the
>
>
>>>>>'workflow scope' is preserved throughout the use-case lifetime, and
>>>>>
>>>>>
>if
>
>
>>>>>for some reason this flow is broken by the user, the workflow scope
>>>>>should be destroyed.
>>>>>
>>>>>I've been able to immitate a workflow scope with the session scope,
>>>>>but it isn't as elegant as I want it to be, or rather, as delimited
>>>>>from the application logic as I'd like it to be... Plus stuff in the
>>>>>session scope hangs around much longer than as if I had a workflow
>>>>>scope.
>>>>>
>>>>>I've been wondering if there's any solutions already to this - it
>>>>>seems that is the _only_ thing Struts is lacking in.
>>>>>
>>>>>Thanks.
>>>>>
>>>>>Martin
>>>>>--
>>>>>
>>>>>
>>>>>Thursday, September 11, 2003, 4:31:29 PM, you wrote:
>>>>>
>>>>>TH> This seems more in scope for some of the ServerSide forums than
>>>>>Struts.
>>>>>
>>>>>TH> http://www.theserverside.com/home/index.jsp
>>>>>
>>>>>TH> Our framework ends where the database begins -:0)
>>>>>
>>>>>TH> Tiles is sufficient for customizating layout and such.
>>>>>
>>>>>TH> -Ted.
>>>>>
>>>>>TH> Gregory Seidman wrote:
>>>>>
>>>>>TH> <snip/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>My purpose in posting this to the list is to get the benefit of the
>>>>>>>membership's collective experience. Is Torque a good choice? Is
>>>>>>>creating a
>>>>>>>separate database for each user unacceptable from the point of view
>>>>>>>of a
>>>>>>>website which provides services on a per-user basis? Is Tiles
>>>>>>>sufficient
>>>>>>>for customizing layout and such? Any suggestions, tales of woe, or
>>>>>>>design
>>>>>>>critiques are appreciated.
>>>>>>>
>>>>>>>Please do not CC me; I am subscribed to the list.
>>>>>>>--Greg
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail:
>>>>>>>struts-user-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>
>>>>_________________________________________________________________
>>>>Get a FREE computer virus scan online from McAfee.
>>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org