ICEfaces
  1. ICEfaces
  2. ICE-5981

Markup rendered by FormRenderer causes D2D DOM-diff after first partial submit

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 2.0-Beta1
          • Fix Version/s: 2.0.0
          • Component/s: None
          • Labels:
            None
          • Environment:
            Liferay 6.0.4 + PortletFaces-Bridge 2.0.0-BETA1 + ICEfaces 2.0 trunk revision 22133

            Description

            Please refer to the attached portlet for a way to reproduce this one.

            When the view is initially rendered with an HTTP-GET, the following <form> appears in the rendered markup of the page:


            <form name="v31jf08" method="post" id="v31jf08" action="http://localhost:8080/web/guest/ice2?_1_WAR_icefaces2xcompatportlet_INSTANCE_Fpb4__facesViewId=%2Fxhtml%2FportletViewMode.xhtml&amp;p_auth=nFDd6uMq&amp;p_p_col_count=1&amp;p_p_col_id=column-1&amp;p_p_id=1_WAR_icefaces2xcompatportlet_INSTANCE_Fpb4&amp;p_p_lifecycle=1&amp;p_p_mode=view&amp;p_p_state=normal">
            <input type="hidden" value="v31jf08" name="v31jf08">
            <input type="hidden" value="http://localhost:8080/web/guest/ice2?p_p_cacheability=cacheLevelPage&amp;p_p_col_count=1&amp;p_p_col_id=column-1&amp;p_p_id=1_WAR_icefaces2xcompatportlet_INSTANCE_Fpb4&amp;p_p_lifecycle=2&amp;p_p_mode=view&amp;p_p_state=normal" name="javax.faces.encodedURL">
            <span id="v31jf08hdnFldsDiv">
            <input type="hidden" name="1360817547:f2:j_idcl">
            <input type="hidden" name="1360817547:f2:j_id1360817547:f2:dateOfBirthsp">
            </span>
            <input type="hidden" autocomplete="off" value="-5481536192991678120:-511719377066662166" id="javax.faces.ViewState" name="javax.faces.ViewState">
            </form>

            But after typing "32801" in the PostalCode field, the DOM-replacement is this:


            <form action="http://localhost:8080/web/guest/ice2?_1_WAR_icefaces2xcompatportlet_INSTANCE_Fpb4__facesViewId=%2Fxhtml%2FportletViewMode.xhtml&amp;p_auth=nFDd6uMq&amp;p_p_col_count=1&amp;p_p_col_id=column-1&amp;p_p_id=1_WAR_icefaces2xcompatportlet_INSTANCE_Fpb4&amp;p_p_lifecycle=1&amp;p_p_mode=view&amp;p_p_state=normal" id="v31jf08" method="post" name="v31jf08">
            <input name="v31jf08" type="hidden" value="v31jf08" />
            <input name="javax.faces.encodedURL" type="hidden" value="http://localhost:8080/web/guest/ice2?p_p_cacheability=cacheLevelPage&amp;p_p_col_count=1&amp;p_p_col_id=column-1&amp;p_p_id=1_WAR_icefaces2xcompatportlet_INSTANCE_Fpb4&amp;p_p_lifecycle=2&amp;p_p_mode=view&amp;p_p_state=normal" />
            <input autocomplete="off" id="javax.faces.ViewState" name="javax.faces.ViewState" type="hidden" value="-5481536192991678120:-511719377066662166" />
            <span id="v31jf08hdnFldsDiv">
            <input name="1360817547:f2:j_idcl" type="hidden" />
            <input name="1360817547:f2:j_id1360817547:f2:dateOfBirthsp" type="hidden" />
            </span>
            </form>

            Even though the form is essentially the same, the order of elements, and the order of attributes on elements is different. This is causing a DOM-diff of the form and an unnecessary incremental page update.

              Activity

              Ascending order - Click to sort in descending order
              6 older comments
              Hide
              Permalink
              Neil Griffin added a comment -

              Ya I noticed that last night. This is due to the ICEfaces 2.0 POM requiring 2.0.3-FCS and the bridge POM requiring 2.0.4-b01. This should be resolved when we sync up on the next release of Mojarra by Oracle.

              Show
              Neil Griffin added a comment - Ya I noticed that last night. This is due to the ICEfaces 2.0 POM requiring 2.0.3-FCS and the bridge POM requiring 2.0.4-b01. This should be resolved when we sync up on the next release of Mojarra by Oracle.
              Hide
              Permalink
              Ted Goddard added a comment -

              The multiple JSF .jars do not appear to be the source of the problem.

              BridgeSetup.java adds a form to the page for retrieveUpdateSetup. ExtrasSetup.java adds *hdnFieldsDiv to all forms. The interaction between these two SystemEventListeners appears to behave differently during initial page view and ajax updates, resulting in different placement of javax.faces.ViewState.

              Since this DOM update does not affect a visible form, it is likely harmless (from the user's point of view), but inefficient.

              Show
              Ted Goddard added a comment - The multiple JSF .jars do not appear to be the source of the problem. BridgeSetup.java adds a form to the page for retrieveUpdateSetup. ExtrasSetup.java adds *hdnFieldsDiv to all forms. The interaction between these two SystemEventListeners appears to behave differently during initial page view and ajax updates, resulting in different placement of javax.faces.ViewState. Since this DOM update does not affect a visible form, it is likely harmless (from the user's point of view), but inefficient.
              Hide
              Permalink
              Ted Goddard added a comment -

              Assigning to Mircea to fix for 2.0 (not essential for beta2). Neil, please let us know if this fix is actually critical for Portlet support and we can re-prioritize for beta2.

              Show
              Ted Goddard added a comment - Assigning to Mircea to fix for 2.0 (not essential for beta2). Neil, please let us know if this fix is actually critical for Portlet support and we can re-prioritize for beta2.
              Hide
              Permalink
              Neil Griffin added a comment -

              The issue is not essential, not critical for portlet support. It is indeed harmless (from the user's point of view). The inefficiency only happens on the first paritalSubmit, and not thereafter.

              Show
              Neil Griffin added a comment - The issue is not essential, not critical for portlet support. It is indeed harmless (from the user's point of view). The inefficiency only happens on the first paritalSubmit, and not thereafter.
              Hide
              Permalink
              Mircea Toma added a comment -

              Removed code that was rendering ViewState input hidden field during postback. This stops ICEfaces from generating an update for the parent 'form' element. In case the form is updated the ViewState input element is restored by the bridge (see ICE-5691 ).

              Show
              Mircea Toma added a comment - Removed code that was rendering ViewState input hidden field during postback. This stops ICEfaces from generating an update for the parent 'form' element. In case the form is updated the ViewState input element is restored by the bridge (see ICE-5691 ).

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Neil Griffin
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: