Hi
DS>> I believe I agree. When exiting a flow the flow being exited should
DS>> be "popped" from the flow call stack and navigation should proceed
DS>> in the context of the calling flow, with navigation originating from that
DS>> flow's call node, and using that flow's navigation rules. The only time
DS>> navigation should use the null flow is when the whole call stack has
DS>> been popped.
Thanks David for the clarification. So in this case it is better that the
"global rules" only apply if the stack is clear. I agree. What's important
here is ensure that the developer can nest 2, 3 or many more flows and
in all cases it will work correctly. The API no matter how is done should
reflect that.
DS>> The existence of the return mode attribute in the interface contract
DS>> seems to suggest we don't have the separation of responsibilities of
DS>> the classes well thought out. It looks like we have a somewhat
DS>> obtuse way of performing a push and pop of a window's flow stack
DS>> using FlowHandler.transition(), FlowHandler.getCurrentFlow(), and
DS>> FlowHandler.setReturnMode(). Maybe it would be more clear if the
DS>> operations on the FlowHandler interface were described as stack
DS>> operations such as push, pop, and peek.
I totally agree with you in this case. Currently we have this:
public abstract Flow getCurrentFlow(FacesContext context)
public abstract void setReturnMode(FacesContext context,
boolean returnMode)
public abstract void transition(FacesContext context,
Flow sourceFlow,
Flow targetFlow,
FlowCallNode outboundCallNode,
String toViewId)
transition() method is ok, because you can't nest the same flow twice.
But trying to implement transition() method, I have found that internally
this method requires a stack to do the job. We need an API that can do
two things:
1. Handle transitions or when to go in/out of a flow, and apply operations
like clear/init flow scope and so on.
2. Calculate the navigation case taking into account the current context,
traversing the flow structure but without execute any of the steps to be
done for the real navigation.
The api we need is something that can do the calculation without affect
the current state, because that part will be done later in
NavigationHandler.handleNavigation() / FlowHandler.transition()
and
clientWindowTransition(FacesContext context).
If some methods resembling push, pop, and peek can do the job it is ok.
The important point here is make the difference between calculate the
next view/outcome and execute the navigation/transitions.
regards,
Leonardo Uribe