Hi
2013/2/28 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Thu, 28 Feb 2013 14:22:25 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>
> LU> Hi
> LU> I have checked again the related parts to OutcomeTarget navigation and
> LU> everything looks good but when you think about 2 chained ReturnNode
> LU> things start to fail.
>
> LU> Consider this use case:
>
> LU> <faces-flow-definition id="flow2">
> LU> <flow-return id="exit2">
> LU> <navigation-case>
> LU> <from-outcome>exit1</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
> LU> <faces-flow-definition id="flow1">
> LU> <flow-return id="exit1">
> LU> <navigation-case>
> LU> <from-outcome>mainpage</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> Two flows, the user enters in flow1 first and then in flow2, but then
> LU> the exit node is triggered. Following the algorithm proposed by
> LU> OutcomeTarget navigation, when the final page before exit in flow2
> LU> is rendered, getNavigationCase() is called, but the generated link
> LU> requires exit from 2 flows. How to synthetize a link for this
> LU> navigation? It is not possible becase you are using 2 query
> LU> parameters, one for the flowId and other for the flowDocumentId, but
> LU> the order is exit from two flows, so there should be two transition
> LU> calls activated from FlowHandler.clientWindowTransition().
>
> This is exactly the scenario of the testcase I shared with you, and it
> does work. The automated test asserts that it works. Here's the flow
> stack:
>
> flow2
> flow1
> root
>
> We are in flow2. We activate "exit2". It returns "exit1". Because the
> system is specified to be operating in return mode during the time when
> getNavigationCase() is being processed as a result of the render request
> from the OutcomeTarget renderer, "exit1" is found within flow1. This
> will look for a flow node named "mainpage".
>
> Now, that "mainpage" *must* be within flow1. If it's not within flow1,
> it will be a navigation that doesn't resolve correctly, which means we
> will stay on the same page.
>
Precisely that's the problem. To make the flow really reusable, the final target
of the return node should be defined in the outer level, no matter how many
nesting levels we have. I know that the solution proposed has sense but I
consider this case can be easily found in practice.
> Leonardo, I think we should have a google hangout where I can step you
> through the code. Will that work? It will have to be the week of March
> 11th because I am on vacation on from the 5th, returning to work on the
> 11th.
>
Yes, sure, no problem. Really I did not considered OutcomeTarget navigation
until the latest snapshot. I do not have anything special to do that week so
let me know when is better for you.
regards,
Leonardo Uribe
> Ed
>
> --