On 02/28/2013 07:41 AM, Leonardo Uribe wrote:
>> In section 7.4.2.1, Requirements for Explicit Navigation in Faces Flow
>> > Call Nodes other than ViewNodes, here is the new text regarding return
>> > nodes.
>> >
>> > If the node is a ReturnNode obtain its navigation case and call
>> > FlowHandler.setReturnMode(true). This enables the navigation to
>> > proceed with respect to the calling flow's navigation rules, or the
>> > application's navigation rules if there is no calling flow. Start the
>> > navigation algorithm over using it as the basis but pass the value of
>> > the symbolic constant javax.faces.flow.FlowHandler.NULL_FLOW as the
>> > value of the toFlowDocumentId argument. If this does not yield a
>> > navigation case, call FlowHandler.getLastDisplayedViewId(), which will
>> > return the last displayed view id of the calling flow, or null if
>> > there is no such flow. In a finally block, when the re-invocation of
>> > the navigation algorithms completes, call
>> > FlowHandler.setReturnMode(false).
>> >
> I don't get these lines. In theory flowDocumentId to use should be the
> parent flow flowDocumentId. So, if the node is a ReturnNode, it should
> take the outcome, and try to resolve it under the parent flow and if
> it resolves to something else the parent flowDocumentId should be
> used. If it founds another ReturnNode it should do the same until
> the top. The rules that are on top (not bound to any flow and set
> globally) only should be consulted if no parent flow is found, respecting
> encapsulation principle.
I believe I agree. When exiting a flow the flow being exited should be
"popped" from the flow call stack and navigation should proceed in the
context of the calling flow, with navigation originating from that
flow's call node, and using that flow's navigation rules. The only time
navigation should use the null flow is when the whole call stack has
been popped.
> I still don't see clearly the usefulness of setReturnMode(false). In my
> opinion it is an internal condition of the navigation algorithm, so it should
> not be on FlowHandler. But maybe this method is suggesting that
> we need another class to calculate the next node in a flow given the
> current context but without affect that context. Something that can
> "simulate" things like enter into a flow or return from a flow and get
> the next current flow.
The existence of the return mode attribute in the interface contract
seems to suggest we don't have the separation of responsibilities of the
classes well thought out. It looks like we have a somewhat obtuse way
of performing a push and pop of a window's flow stack using
FlowHandler.transition(), FlowHandler.getCurrentFlow(), and
FlowHandler.setReturnMode(). Maybe it would be more clear if the
operations on the FlowHandler interface were described as stack
operations such as push, pop, and peek.
Dave
>
> regards,
>
> Leonardo Uribe
>