[Struts Workflow] - The workflow definition should allow for dynamic navigation

[Pedro Rodriguez <pr...@accovia.com>]

I feel that the workflow definition, beside of violation detection,
should allow for dynamic navigation.
 
The framework should provide "tools" to help building apps that's
follows de right workflow. I think of a preventive approach instead of
exclusively relating in postmortem violations detection. 
 
Somehow providing features to support the following requirements: 
 
1-     Allow actions need to be "decided" in the JSP page.
2-     Some generic actions need to route to a specific Action based on
"workflow" status.
 
Do you agree?
 
Thanks a lot,
 
Pedro Rodriguez
 
 

Re: [Struts Workflow] - The workflow definition should allow for dynamic navigation

[Matthias Bauer <ma...@livinglogic.de>]

First of all my apologies for the late response to your mails you also 
sent to me personally, but I was on vacation and did not check my 
E-Mails for quite a while.

>I feel that the workflow definition, beside of violation detection,
>should allow for dynamic navigation.
> 
>The framework should provide "tools" to help building apps that's
>follows de right workflow. I think of a preventive approach instead of
>exclusively relating in postmortem violations detection. 
>[...]
>
Up to now this was beyond the scope of the workflow extension. But if 
you are willing to enhance the standard functionality to cover these 
issues, that's fine with me.

>I think it is not a good idea to process "newState" and "endWorkflow"
>before executing the Action. 
> 
>Problem:
> 
>The fact is that an Action can fail. If that happens, such anticipated
>state transitions and cleanups are undesired.
> 
>Drawbacks of the current design:
> 
>If an Action mapping includes "newState" or "endWorkflow" then some sort
>of "rollback" must be defined to handle Action's failures.
> 
>Instead of going directly to a jsp on every failure (as normal) we
>should navigate to a "rollback" action mapping where all modified
>workflows states are restituted. The challenge here is to know which
>such state was!!!
> 
>Also, the custom rollback implementation must provide the reactivation
>of those workflows prematurely destroyed.
> 
>Solution
> 
>Struts don't formalize "Action failure" so there is no way for
>StrusWorkflow to know if the Action succeeded or not. 
> 
>However, we should define one. For example, a property "failureForward".
>
> 
>The user can specify all forwards representing failures (adding
>failureForward properties to the Action mapping). 
> 
>In Struts, using the resulting forward path we can determine the
>forward. 
> 
>If no forward can be determined (no forward was used to create the
>resulting forward path) or if the resulting forward doesn't represent a
>failure then we proceed to perform the specified "newState" and
>"endWorkflow.
> 
>If the action fails, no "newState" nor "endWorkflow" must be processed.
> 
>The WorkflowRequestProcessor/TilesWorkflowRequestProcessor can easily
>handle that. 
> 
>Unhandled exceptions
> 
>The same discussed for Action failures forwards applies for uncatched
>exceptions.
> 
>If the Action execution is aborted due to an uncatched exception (being
>handle by a Struts error handler or whatever) no "newState" nor
>"endWorkflow" shouldn't be processed either.
>  
>
I see your point and I certainly have shed some thoughts on this issue 
as well. I decided against introducing a special forward definition or 
an action property for failure cases like you propose. I admit that this 
approach might appear odd at first, but on the other hand it makes the 
mechanism more straightforward: Each time an action is executed, it 
updates the state information. You can simply rely on that fact. If you 
want to rollback the state you can always do that with an appropriate 
action. Maybe you can elaborate more deeply some cases when this 
approach does not work for you.

--- Matthias


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org