jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [730-Flows] OutcomeTarget flow navigation (clientWindowTransition() also handle navigation)

From: Edward Burns <edward.burns_at_oracle.com>
Date: Fri, 15 Mar 2013 20:11:47 -0700

>>>>> On Tue, 12 Mar 2013 23:20:12 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:

LU> Hi
LU> 2013/3/12 Edward Burns <edward.burns_at_oracle.com>:
>>>>>>> On Sun, 10 Mar 2013 22:09:24 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>>
LU> But what happen if I copy the link into a new browser tab?

EB> That is not supposed to work because, by definition, the flow system is
EB> entirely built on ClientWindow, which, by definition is bound to a
EB> browser view (such as a tab or window).

LU> Yes, I know it does not work, it should not work, but the problem is
LU> how faces flow fails under such circumstance.

I have filed
<http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1173> to cover
this and your other concern in your email.

LU> Other point I realize is clientWindowTransition() really is
LU> calculating and performing navigation, and in few words, isn't that
LU> a responsibility from NavigationHandler ? Shouldn't that code be
LU> there?

I wish I could, but because of the fact that it needs to happen at the
beginning of the lifecycle on the GET->GET based navigation, it has to
happen within there. Please recall that in the "usual"
POST->rd.forward() style of navigation everything can happen within
NavigationHandler. With GET->GET navigation, some of the navigation
happens during rendering, and the other half of the navigation happens
when the user activates the component that sends the GET. Because of
this disconnect, I had to carve out a piece of the navigation and
encapsulate it in clientWindowTransition().

Ed