>>>>> 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?