Re: [PARTLY SOLVED] workflow - Re: integration with other app
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 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" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> 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 ac
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 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" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > 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 Ba
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" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > 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 no
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 <[EMAIL PROTECTED]> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> 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> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -
Re: workflow - Re: integration with other app
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 <[EMAIL PROTECTED]> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> 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> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: workflow - Re: integration with other app
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> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
workflow - Re: integration with other app
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> >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
