Details

      Description

      According to the portlet specification, elements such as <head>, <title>, and <body> may not be output to the response by a portlet.

      Because of this, the FacesBridge must prevent the Faces runtime from writing <body>...</body> to the response when it invokes the renderer for <h:body/>. Instead, the FacesBridge must ensure that a <div>...</div> is written and the value of the "id" attribute must be the clientId of the UIViewRoot.

      The FacesBridge must also support the following use-case:

      faceletView.xhtml
      <?xml version="1.0" encoding="UTF-8"?>
      <f:view xmlns="http://www.w3.org/1999/xhtml"
      	xmlns:f="http://xmlns.jcp.org/jsf/core" xmlns:h="http://xmlns.jcp.org/jsf/html"
      	xmlns:ui="http://xmlns.jcp.org/jsf/facelets" xmlns:c="http://xmlns.jcp.org/jsp/jstl/core">
      	<h:head />
      	<h:body>
      		<h:form>
      			<h:commandButton>
      				<f:ajax execute="@form" render="@all" />
      			</h:commandButton>
      		</h:form>
      	</h:body>
      </f:view>
      

      When the commandButton is clicked, this will cause a partial-response similar to the following to be generated by the FacesRuntime:

      <partial-response id="j_id1">
      	<changes>
      		<update id="javax.faces.ViewRoot">
      			<![CDATA[...]]>
      		</update>
      	<update id="j_id1:javax.faces.ViewState:0">
      		<![CDATA[ -234567890098765432:123456789076543217 ]]>
      	</update>
      	</changes>
      </partial-response>
      

      The FacesBridge must ensure that only the <div>...</div> is replaced in the client rather than the entire <body>...</body>.

      The manner in which the FacesBridge fulfills this requirement is an implementation detail. One possibility is for the FacesBridge to provide a custom jsf.js resource. Another might be for the FacesBridge to introduce a custom ResponseWriter that monitors calls to ResponseWriter.startElement(String name, UIComponent component) and ResponseWriter.writeAttribute(String name, Object value, String property) in order to transform value of the id attribute from "javax.faces.ViewRoot" to the id of the <div>...</div>.

      As a consequence of the FacesBridge specifying the id of the <div>...</div> "javax.faces.ViewRoot", the JavaScript code in the Mojarra implementation of jsf.js will not be able to dynamically add the <input type="hidden" name="javax.faces.ViewState"/> hidden field to forms. Because of this, FacesBridge must ensure that this takes place, but the manner in which it takes place is an implementation detail. Note that this will not be a problem with JSF 2.3, due to the solution provided by JAVASERVERFACES_SPEC_PUBLIC-790 in the FacesRuntime.

      TCK: renderAllTest

      • Two portlets exist on the portal page: PortletA, PortletB
      • PortletB has has two forms: FormA, FormB
      • Submit the second form with <f:ajax execute="@form" render="@all" />
      • Verify that the DOM was only updated for PortletB and that both forms in PortletB have a hidden field with "javax.faces.ViewState" as part of the name attribute.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: