Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      There are three main portlet incompatibilities/limitations in the jsf.js JavaScript code:

      1. The <?xml version="1.0" encoding="UTF-8"> and <!DOCTYPE> markers is assumed to be valid to keep in the response because jsf.js assumes a servlet environment in which the rendered JSF view takes up the entire DOM in the userAgent/browser.

      One current portlet bridge workaround for #1 is to simply strip out the offending markers.

      2. During "partial" updates in which the javax.faces.ViewRoot is being replaced in the DOM (which is basically a full update of the view – not really partial), jsf.js attempts to replace everything inside the <body>...</body> elements, which of course is a servlet environment assumption. Instead, it should be the outermost <div> tag rendered by the bridge's BodyRenderer that should be replaced in the DOM.

      One current portlet bridge workaround for #2 is to substitute the id value of "javax.faces.ViewRoot" with the id of the outermost <div> tag rendered by the bridge's BodyRenderer.

      3. Also in the the case of a "partial" update of javax.faces.ViewRoot, jsf.js attempts to dynamically create the javax.faces.ViewState hidden input field if it is not found in the form. The JavaScript code will successfully do
      this provided it is permitted to replace everything inside the <body>...</body> elements, but since we can't let that happen in a portlet environment, the hidden field does not get created.

      One current portlet bridge workaround for #3 is to inject the javax.faces.ViewState hidden field into the response if it is not already there.

        Issue Links

          Activity

          Show
          Ed Burns added a comment - It's in the frame maker document. http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aworklog-tabpanel#action_14496
          Hide
          Neil Griffin added a comment -

          OK thanks Ed.

          Show
          Neil Griffin added a comment - OK thanks Ed.
          Hide
          Manfred Riem added a comment -

          After discussing this with Neil I think the best way to solve this problem is to actually effectuate a patch in the PartialViewContextImpl.renderAll where we check if the request is a Portlet request and if it is we render the id of the UIViewRoot as if we are replacing a regular component, and if it is a regular Servlet request we do what the current implementation does.

          The previously spec language about this can be removed from the 2.2 spec. We can add spec language to PartialViewContext to cover this case if so desired.

          Show
          Manfred Riem added a comment - After discussing this with Neil I think the best way to solve this problem is to actually effectuate a patch in the PartialViewContextImpl.renderAll where we check if the request is a Portlet request and if it is we render the id of the UIViewRoot as if we are replacing a regular component, and if it is a regular Servlet request we do what the current implementation does. The previously spec language about this can be removed from the 2.2 spec. We can add spec language to PartialViewContext to cover this case if so desired.
          Hide
          Ed Burns added a comment -

          On 20121128, Neil Griffin wrote:

          NG> However I do not see the JavaDocs updated for
          NG> PartialResponseWriter.startUpdate(String) [1]

          NG> Recommendation was to change the language to something like:

          NG> "Write the start of an update operation. If the specified targetId
          NG> is equal to

          {@link PartialResponseWriter#RENDER_ALL_MARKER}

          NG> (javax.faces.ViewRoot) then the id of the outermost <div> should be
          NG> written instead of the specified targetId."

          On 20130220, Manfred Riem wrote:

          MR> After discussing this with Neil I think the best way to solve this
          MR> problem is to actually effectuate a patch in the
          MR> PartialViewContextImpl.renderAll where we check if the request is a
          MR> Portlet request and if it is we render the id of the UIViewRoot as
          MR> if we are replacing a regular component, and if it is a regular
          MR> Servlet request we do what the current implementation does.

          This sounds good. This behavior is described in 2.2.6.1 Render Response
          Partial Processing. The existing text is:

          Existing> If isRenderAll() returns true, call
          Existing> startUpdate(PartialResponseWriter.RENDER_ALL_MARKER) on the
          Existing> PartialResponseWriter. For each child of the UIViewRoot, call
          Existing> encodeAll(). Call endUpdate() on the
          Existing> PartialResponseWriter. Render the state using the algorithm
          Existing> described below in Section Partial State Rendering, call
          Existing> endDocument() on the PartialResponseWriter and return.

          I propose the following text instead:

          New> If isRenderAll() returns true and this is a non-portlet request,
          New> call startUpdate(PartialResponseWriter.RENDER_ALL_MARKER) on the
          New> PartialResponseWriter. For each child of the UIViewRoot, call
          New> encodeAll(). Call endUpdate() on the PartialResponseWriter. Render
          New> the state using the algorithm described below in Section Partial
          New> State Rendering, call endDocument() on the PartialResponseWriter
          New> and return. If isRenderAll() returns true and this is a portlet
          New> request, treat this as a case where isRenderAll() returns false,
          New> but use the UIViewRoot as the one and only component from which the
          New> tree visit must start.

          Show
          Ed Burns added a comment - On 20121128, Neil Griffin wrote: NG> However I do not see the JavaDocs updated for NG> PartialResponseWriter.startUpdate(String) [1] NG> Recommendation was to change the language to something like: NG> "Write the start of an update operation. If the specified targetId NG> is equal to {@link PartialResponseWriter#RENDER_ALL_MARKER} NG> (javax.faces.ViewRoot) then the id of the outermost <div> should be NG> written instead of the specified targetId." On 20130220, Manfred Riem wrote: MR> After discussing this with Neil I think the best way to solve this MR> problem is to actually effectuate a patch in the MR> PartialViewContextImpl.renderAll where we check if the request is a MR> Portlet request and if it is we render the id of the UIViewRoot as MR> if we are replacing a regular component, and if it is a regular MR> Servlet request we do what the current implementation does. This sounds good. This behavior is described in 2.2.6.1 Render Response Partial Processing. The existing text is: Existing> If isRenderAll() returns true, call Existing> startUpdate(PartialResponseWriter.RENDER_ALL_MARKER) on the Existing> PartialResponseWriter. For each child of the UIViewRoot, call Existing> encodeAll(). Call endUpdate() on the Existing> PartialResponseWriter. Render the state using the algorithm Existing> described below in Section Partial State Rendering, call Existing> endDocument() on the PartialResponseWriter and return. I propose the following text instead: New> If isRenderAll() returns true and this is a non-portlet request, New> call startUpdate(PartialResponseWriter.RENDER_ALL_MARKER) on the New> PartialResponseWriter. For each child of the UIViewRoot, call New> encodeAll(). Call endUpdate() on the PartialResponseWriter. Render New> the state using the algorithm described below in Section Partial New> State Rendering, call endDocument() on the PartialResponseWriter New> and return. If isRenderAll() returns true and this is a portlet New> request, treat this as a case where isRenderAll() returns false, New> but use the UIViewRoot as the one and only component from which the New> tree visit must start.
          Hide
          Ed Burns added a comment -

          Verified with Manfred that the required text is in section 2.2.6.1.

          Show
          Ed Burns added a comment - Verified with Manfred that the required text is in section 2.2.6.1.

            People

            • Assignee:
              Ed Burns
              Reporter:
              Neil Griffin
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours, 18 minutes
                2h 18m