In order to make the intermediate page GET work in a portlet environment, I think jsf.js would have to use a special URL that would invoke a javax.portlet.ResourceRequest. Perhaps we could just use the javax.faces.encodedURL hidden field [1] that is rendered by the FormRenderer?
The problem is that javax.portlet.ResourceResponse [2] does not have a redirect method. Therefore I think it would be necessary for the intermediate page to invoke a redirect similar to the PartialResponseWriter logic described in ExternalContext.redirect(String) [3]
Neil
[1]
http://javaserverfaces.java.net/nonav/docs/2.0/renderkitdocs/HTML_BASIC/javax.faces.Formjavax.faces.Form.html
[2]
http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletResponse.html
[3]
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#redirect(java.lang.String)
On Mar 16, 2012, at 9:02 AM, Werner Punz wrote:
> Am 14.03.12 20:02, schrieb Edward Burns:
>>
>>>>>>> On Mon, 12 Mar 2012 14:00:20 -0700, Edward Burns <edward.burns_at_oracle.com> said:
>> EB> Summary: Please correct me if I'm wrong but all that remains for this
>> EB> feature in JSF 2.2 is to concretely specify url-mode and make it
>> EB> reasonably easy to override and decorate to provide custom-mode.
>>
>> Here's another big commit on this issue.
>>
>> Add URL mode. After this commit, there are three outstanding issues
>>
>> 1.What do we need to say in jsf.js to properly handle url-mode in the
>> case when the user opens a new tab. I think we need to say something
>> in that case, but I need some help, perhaps from Werner Punz, to learn
>> what to say.
>>
>> ACTION: Werner Punz, can you please help here?
> Actually i doubled checked my answer with Gerhard and Mark which basically
> did all this for CODI, I personally think CODI has an interesting and provenly working
> approach:
>
> Well in CODI there is an optional Javascript for handling edge cases and an intermediate page.
> The basic idea is, that every GET request will always (ok, based on the user-agent)
> first return a neutral intermediate page which checks if the window.name matches the
> windowId URL parameter. If the name is not present or does not match then a redirect
> to the page is performed with a blank windowid, the implementation then generates a new one.
> Otherwise (we are in the correct browser tab) the request will 1:1 be sent a second time,
> and this time returning the real destination JSF page.
>
> If the window.name is present as is, the redirect happens as is with all parameters,
> the old windowid etc...
>
> This approach is necessary, because if this would not go through an intermediate page,
> then managed beans could be destroyed.
>
> The problem there is that you will get a short flickering due to the intermediate page.
> On html5 enabled browsers with local storage this flickering can be fixed on legacy browsers not.
>
> So to sum it up swiftly
> a) Every GET access goes to intermediate page, in case of no window.name redirect to page
> without windowid, otherwise redirect the get request with the windowid
>
>
> Another approach which is not bean save which can be enabled in CODI is following:
>
> b) render the page initially -> check for the window name -> redirect without windowid to
> itself, that way the flickering does not occur on legacy browsers but you have situations
> where the beans state could be disturbed.
>
> Werner
>
>
>> 2.Make it so the flash is based on the WindowId, if present. I'm not
>> entirely convinced we need this one, though.
>>
>> ACTION: Leonardo, can you please tell me why you feel this is important.
>>
>> 3.Make changes to the renderkit doc so that tags that render links have
>> an additional attribute that prevents the windowId from being appended to
>> that link.
>>
>> I'll do this one for <h:link> only, unless someone tells me otherwise.
>>
>> Here's a guide to the feature to aid in review, taken from the class
>> javadocs for ClientWindow.
>>
>> This class represents a client window, which may be a browser tab,
>> browser window, browser pop-up, portlet, or anything else that can
>> display a UIComponent hierarchy rooted at a UIViewRoot.
>>
>> Modes of Operation
>>
>> none mode
>>
>> The generation of ClientWindow is controlled by the value of the
>> context-param named by the value of
>> WINDOW_ID_MODE_PARAM_NAME. If this context-param is not
>> specified, or its value is "none", no ClientWindow instances
>> will be generated, and the entire feature is effectively
>> disabled for the entire application.
>>
>> Other modes
>>
>> For all other valid values of WINDOW_ID_MODE_PARAM_NAME,
>> including custom values not explicitly covered in this
>> specification, the lifetime of a ClientWindow starts on the
>> first request made by a particular client window (or tab, or
>> pop-up, etc) to the JSF runtime and persists as long as that
>> window remains open or the session expires, whichever comes
>> first. A client window is always associated with exactly one
>> UIViewRoot instance at a time, but may display many different
>> UIViewRoots during its lifetime.
>>
>> The ClientWindow instance is associated with the incoming
>> request during the
>> Lifecycle.attachWindow(javax.faces.context.FacesContext)
>> method. This method will cause a new instance of ClientWindow to
>> be created, assigned an id, and passed to
>> ExternalContext.setClientWindow(javax.faces.lifecycle.ClientWindow).
>>
>> During state saving, regardless of the window id mode, or state
>> saving mode, a hidden field must be written whose name, id and
>> value are given as specified in
>> ResponseStateManager.WINDOW_ID_PARAM.
>>
>> url mode
>>
>> If the value of the WINDOW_ID_MODE_PARAM_NAME is "url",
>> without the quotes, the encoding of the ClientWindow must be
>> performed as follows, in addition to the hidden field already
>> described. The runtime must ensure that any component that
>> renders a hyperlink that causes the user agent to send a GET
>> request ow().
>>
>> M jsf-api/src/main/java/javax/faces/lifecycle/ClientWindow.java
>>
>> The heart of the spec for the feature.
>>
>> M jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java
>>
>> Constants, their names, and values.
>>
>> M jsf-api/src/main/java/javax/faces/context/ExternalContext.java
>>
>> encodeActionURL() and related methods
>>
>> M jsf-api/src/main/resources/jsf.js
>>
>> Unrelated: increment version number to 2.2.
>>
>> M jsf-ri/src/main/java/com/sun/faces/context/UrlBuilder.java
>> M jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
>>
>> Changes related to url-mode.
>>
>> M jsf-ri/src/main/java/com/sun/faces/lifecycle/ClientWindowImpl.java
>>
>> Implement the feature
>>
>> M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/main.xhtml
>> M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/WEB-INF/web.xml
>> A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/page2.xhtml
>> M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_htmlunit/src/main/java/c
>> M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_htmlunit/src/main/java/com/sun/faces/test/i_spec_949_htmlunit/IssueSpec949TestCase.java
>>
>> Test the feature
>>
>> M nbproject/project.xml
>>
>> spell checker
>>
>> M jsf-api/doc/standard-html-renderkit-base.xml
>>
>> Unrelated, fix typo in link renderer spec.
>>
>