Hi Matthias, Thanks for the response. Right now I my requirements are mostly satisfied by the workflow extention.But as pointed out in another recent mail, the ability to specify just one workflow violation forward per workflow is a bit constraining.Can you not provide atleast 2 workflow violation forwards per workflow? This will allow the user the configure different page forwards in case of previous state condition violation and nest state condition violation.Because I have exactly same requirements for some of my pages.Following is the scenario.
Order Entry workflow: 1.page 1 :user selects order parameters and presses ok button. 2.page 2 :order review screen.User can review the order details and then say ok or cancel. 3.page 3. User gets the confirmed order details if he says ok. Now the requirement is as follows. 1.If the user is in the middle of order entry workflow(say page 2:order review screen) and from there he leaves the workflow by clicking some link on menu item.In this case he should be allowed to leave the workflow but just a proper warning should be displayed on the next page (The page he selected from Menu). 2.The user tries to jump directly in the middle of workflow.(By using bookmark or by typing the URL of say page 2:order review screen)In this case he should be thrown back to page 1 of workflow(Order entry screen with proper warning.) Now as you can see, case 1 is next state violation and case 2 is previous state violation and I want to handle those differently.Also as I want to add a warning in those cases, a post processing hook to the workflow request processor/or workflowProcessorLogic will be very helpful so that I can add such functionality by extending the workflowProcessorLogic or workflow request processor. Also about extending the WorkFlowLogic class,most of the other classes have package constructors or their methods are package level /private visibility.So if you can also look into this , it will benefit a lot of users like me who want to extend the functionality of the WorkFlow extension. All said, I must congratulate you on this very well designed extension.Because after some studies, we found that it meets most of our requirements. Any suggestions about achieving above mentioned functionality without extending the framework will be really useful. Regards, Shirish. -----Original Message----- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 9:47 AM To: Struts Users Mailing List Subject: Re: [struts workflow extension] design question [EMAIL PROTECTED] wrote: >Thanks Matthias, > >I will have a close look at the demo and test applications.I need some generic way to >add the workflow extention to my existing working screens so that the user will be >kept informed of the workflow violations and given a choice to leave the workflow or >stay in the workflow.So I am looking at some way to write a generic action which will >allow the user to terminate or continue in the workflow. > >Any how, I will first look at the applications included with download bundle.I hope >that i will not be required to extend the workFlowProcessorLogic. > You really should not. If there is some required functionality missing to accomplish this, I am certainly interested in incorporating this. Thus, please let me know, if you are not able to meet your reqirements with the current version of the extension. >But I still have my original doubt.Why does the WorkflowRequestProcessorLogic class >not have a public constructor?Should it not be extendable?Or it was a design decision >due to some reasons.Because I think keeping in line with the struts philosophy, you >could give a couple of extension points in your framework.And the way it is designed, >I dont see a reason why it will not become a defacto extention for workflow problems. > > It was just an oversight not to provide a public constructor. Will keep this in my todo list and fix it in the next release. --- Matthias --------------------------------------------------------------------- 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]
