Hi Guys,
For JSF 2.2 portlet alignment, I think it's important (from a design perspective) to fix servlet environment assumptions in the JSF API or Spec. If such assumptions are present in a JSF implementation, then the portlet bridge can simply perform overrides at the proper extension points. The solutions below seem reasonable to me, since they appear to be implementation details that do not affect existing JSF applications.
Regarding #1, the solution of writePreamble() seems good. The portlet bridge override of PartialResponseWriter can simply avoid writing the preamble.
Regarding #2, the solution also seems good. The bridge's BodyRenderer could simply write the <div> tag and avoid writing the <body> tag.
Additionally, in order to keep PartialResponseWriter#RENDER_ALL_MARKER [1] backwards compatible, then I think that the JavaDoc requirements for PartialViewContext#startUpdate(String) [2] method should be changed to something like this:
"Write the start of an update operation. If the specified targetId is equal to {_at_link PartialResponseWriter#RENDER_ALL_MARKER} then the id of the outermost <div> should be written instead."
That way, jsf.js would work in both servlet and portlet environments, and we avoid a big change like UIViewRoot implementing NamingContainer or something like that.
Regarding #3, yes if #2 were fixed then I think #3 gets fixed automatically.
Thanks,
Neil
[1]
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/PartialResponseWriter.html#RENDER_ALL_MARKER
[2]
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/PartialResponseWriter.html#startUpdate(java.lang.String)
On Feb 17, 2012, at 5:08 PM, Blake Sullivan wrote:
> 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?
>