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]
