I am not sure, but let me try to express in my own words, what I believe you want to do: The user tries to access startWizard1.do or startWizard2.do. They are both access protected, so if the user is not logged in, he will be forwarded to displayLogin.do. Now after he has correctly logged in, you want him to get to startWizard1.do or startWizard2.do, depending which action he chose before. Is this correct?
If this is the problem, you are trying to solve, it should be easy: Build an action (e. g. SaveCurrentRequestAction) and associate it with the global authenticationException forward. This action should simply store the requested path (you can get that from the request object) in the the session. Then after the login succeeds, you forward to this path.
Hope I got your question right,
--- Matthias
Adam L wrote:
Matthias:
Thank you for the clearer explanation.
If I understand this now, if I change all my current workflow violation forwards to be of type ForwardNextStateViolationAction (they are all currently just plain actions with a forward, no type specified), then the existing workflow will work as originally designed, keeping the flow in process, with both prev and next violations triggering and performing as appropriate to this workflow, but an external workflow (launched from another menu option) will be allowed to start if the user so chooses, without being forced back into their first workflow.
and the moral of the story is: a truly modal workflow process should have violations defined as:
<action path="/wkfAddNewInfoViolation" forward="/content/displaySelectionScreen.jspa" />
while a workflow process that can be interrupted by other workflows will have violations defined as:
<action path="/wkfAddNewInfoViolation" type="ForwardNextStateViolationAction"> <forward name="noNextStateViolation" path="/content/displaySelectionScreen.jspa" /> <!-- external forward (external process selected) is implicit --> </action>
I think that indeed solves my problem. Now I'm trying to see how I can use this for cases where an authentication fails, for instance a user is required to be logged in first: <set-property property="authClass" value="com.foo.workflow.authentication.LoggedInAuthentication" /> <forward name="authenticationException" path="/login.do" />
How would I chain them to the login (or whichever) process, and then bring them back to the step they were trying to perform prior? I'm currently seeing this as having to declare several instances of the login process as actions, some rigged to the main menu login, others rigged from each workflow that requires this authentication. This seems like a lot of extraneous work, and also requires this new subflow to be defined for every workflow where this authentication is utilized. That, or wrap the process in chain of Actions that pass a token along that somehow says "when you're done with this entire flow, come back to this location". I'm going to have to ponder on this. Do you have any thoughts on how this could easily be achieved using your framework?
Thank you again for all your help and thought!
-- adam
----- Original Message ----- From: "Matthias Bauer" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, October 07, 2003 3:20 AM Subject: Re: workflow extension question
Adam,
sorry that I obviously did not make myself clear enough. Look at the following definitions:
global-forwards: workflowViolation_wiz1step1: violatedWizard1Step1 workflowViolation_wiz1step2: violatedWizard1Step2
displayWizard1Step1 primaryWorkflow: wiz1step1 newState: displayed nextState: submitted
submitWizard1Step1 primaryWorkflow: wiz1step1 prevState: displayed newState: submitted forward=success: displayWizard1Step2
displayWizard1Step2 secondaryWorkflow: wiz1step1 prevState: submitted primaryWorkflow: wiz1step2 newState: displayed nextState: submitted
submitWizard1Step2 primaryWorkflow: wiz1step2 prevState: displayed newState: submitted
violatedWizard1Step1 type: ForwardNextStateViolationAction forward=noNextStateViolation: displayWizard1Step1
violatedWizard1Step2 type: ForwardNextStateViolationAction secondaryWorkflow: wiz1step1 endWorkflow: true forward=noNextStateViolation: displayWizard1Step2
This is what can happen: If the user has just executed "displayWizard1Step1" he can only execute "submitWizard1Step1" without causing a workflow violation. If for instance he follows a link from the menu, the workflow "wiz1step1" is executed, which causes the execution of action "violatedWizard1Step1". Upon workflow violation of "wiz1step1", this workflow is automatically cleaned up, so this action does not need to do any other cleanup work. The action class "ForwardNextStateViolationAction" forwards to the action the user has chosen from the menu after that.
Upon prevState violations, i. e. if the user executes "submitWizard1Step1" without having executed "displayWizard1Step1" before, the action "violatedWizard1Step1" causes a forward to "displayWizard1Step1".
If a workflow violation of "wiz1step2" happens, the action "violatedWizard1Step2" is executed, which also ends and cleans up the workflow "wiz1step1". Except the mechansims are identical to workflow "wiz1step1".
This should meet your requirements. Or am I still missing something?
Concerning your question whether this approach is better than the one to end all workflows: In many cases you do not want to end all workflows, but only these that belong to a certain process (in our example all workflows belonging to wizard1).
Please let me know, if there are still further questions.
--- Matthias
Adam Levine wrote:
Matthias: I think I understand your answer. But, I'm not sure where things would go. If I'm understanding your explanation:
process1:wkfl1 -> process1:wkfl2 -> (violation) process2:wkfl1 landing page(initializer action)
the p2:w1 landing page would be a ForwardNextStateViolationAction the FordwardNextStateViolationAction has forwards: forward "noNextStateViolation" : goes to display page for p2:w1
but, if there IS a next state violation, here's where I get confused: "If a nextState violation was encountered it forwards to the path that caused this workflow violation "
Which would lead me back to the p2:w1 landing page ? That confuses me.
Can you explain why this approach is better than just a "i know i want to end all previous processes at this point, without having to link in with other violation actions" ? Or can they co-exist together nicely ?
Thanks for your help.
-- adam
--------------------------------------------------------------------- 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]