I guess I would question whether any fixes for 1) or 2) are necessary.
The proposal before is to make non-backwards compatible behavior
changes. For such a change, I would want to see some clear benefits.
In this case, the Bridge has a work-around. It doesn't sound like the
work-around is hurting performance--nor does it sound like the Bridge is
being asked to do something outside of its purview--which in this case
is turning a document-oriented page into a fragment.
-- Blake Sullivan
On 2/17/12 1:52 PM, Edward Burns wrote:
>>>>>> On Mon, 13 Feb 2012 13:43:11 -0500, Neil Griffin<neil.griffin_at_portletfaces.org> said:
> NG> I did a search in JIRA and it seemed that there were 3 semi-related
> NG> issues. Since none of them described the full import of the problems
> NG> with jsf.js and portlets, I created the following new issue and
> NG> linked the semi-related issues:
> NG> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069
>
> NG> 1. The<?xml version="1.0" encoding="UTF-8"> and<!DOCTYPE> markers
> NG> is assumed to be valid to keep in the response because jsf.js
> NG> assumes a servlet environment in which the rendered JSF view takes
> NG> up the entire DOM in the userAgent/browser.
>
> FWIW, Mojarra doesn't seem to write a DOCTYPE for ajax responses, but it
> does write an XML preablble.
>
> I note that you are already accustomed to providing your own
> FaceletContext implementation in the portlet bridge. Further, note that
> FaceletContext vends PartialResponseWriter. I suggest that we extract
> the writing of the XML preamble to a new method on
> PartialResponseWriter: writePreamble(). We change the spec of
> PartialViewContext.processPartial() to require calling writePreamble()
> before startDocument(). Then, in the portlet override of
> PartialResponseWriter, portlet can do the right thing with respect to
> writing the preamble or not.
>
> NG> 2. During "partial" updates in which the javax.faces.ViewRoot is
> NG> being replaced in the DOM (which is basically a full update of the
> NG> view \u2013 not really partial), jsf.js attempts to replace everything
> NG> inside the<body>...</body> elements, which of course is a servlet
> NG> environment assumption. Instead, it should be the outermost<div>
> NG> tag rendered by the bridge's BodyRenderer that should be replaced in
> NG> the DOM.
>
> NG> One current portlet bridge workaround for #2 is to substitute the id
> NG> value of "javax.faces.ViewRoot" with the id of the outermost<div>
> NG> tag rendered by the bridge's BodyRenderer.
>
> Would it be sufficient here to modify the specification of BodyRenderer
> so that it always renders<body><div> (and the corresponding end tags)
> and also change the specification of jsf.js so that finds that outer
> most div and replaces that?
>
> NG> 3. Also in the the case of a "partial" update of
> NG> javax.faces.ViewRoot, jsf.js attempts to dynamically create the
> NG> javax.faces.ViewState hidden input field if it is not found in the
> NG> form. The JavaScript code will successfully do this provided it is
> NG> permitted to replace everything inside the<body>...</body>
> NG> elements, but since we can't let that happen in a portlet
> NG> environment, the hidden field does not get created.
>
> It would seem that fixing 2. would make it possible to fix 3. Do you
> agree?