first of all: Thank you. I certainly like to hear that the Struts Workflow Extension meets your requirements and you like the approach I have taken.
Regarding the general need to distinguish nextState and prevState violations: There is an action contained in the package that can easily be used to handle exactly the cases you are talking about: ForwardNextStateViolationAction. Here is, what it is meant for: 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). If you want to put a message in request/session scope when this happens, just write a slightly modified action which is pretty similar to ForwardNextStateViolationAction that additionally takes care of saving the message. Have a look at the action's code: It uses the method WorkflowUtils.getNextStateViolationAction that provides the required information.
I chose to take this approach for the following two advantages:
1. the number of global forwards stays smaller, as there is only one global forward definition per workflow + in many situations you don't even care whether it was a prevState or nextState violation
2. if you need to distinguish whether you are dealing with a prevState or nextState violation and can retrieve the action path that caused the workflow violation, do whatever you like and forward the user to this path he requested
Concerning your other request for extendability: Yes, I will take care of that. Even though it is sometimes good to have extendability restricted, because people tend to reimplement their own solutions while there are already the right mechanisms available. ;-)
Hope this additional info helps.
--- Matthias
[EMAIL PROTECTED] wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
