ICEfaces
  1. ICEfaces
  2. ICE-6352

Changes to Component inner hierarchy does not always update javascript

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Beta2
    • Fix Version/s: 2.0.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEFaces ACE components

      Description

      I've noticed this issue on the LinkButton, but it should manifest in all ACE components under the right circumstances.

      The HTML structure built by the renderer encapsulating a LinkButton looks like this:

      <div>
        <span id="xxx_span" >
           <span class="first-child">
               <a> A child node </a>
           </span>
        </span>
        <span id="xxx_script">
          <script> Yadda </script>
        </span>
      </div>

      The problem occurs when there is some behaviour that changes the markup in the span with the id "xxx_span", "first-child", or the anchor tag. The reason is that our dom-diffing algorithm finds the first parent element with an id and applies an update to that element. This excludes the javascript span and the <script> element is not reevaluated by the client.

      In the case of LinkButton, my test page changes the style string on one of the inner spans of the anchor hierarchy. It's necessary to change the style on this level or it wont override the default Sam or Rime styling, and this sends an update of just the inner <span> tags which causes the YUI component that was created on the initial update to be replaced with simple html since the initialize method in the javascript is not re-executed. This manifests most visibly when the linkButton value attribute is replaced on the link with the normal html value of: "A child node", in the above case.

      The component renderer is going to need to keep track of elements and attributes which are on the innermost elements of a nested component structure, and if they change, going to have to write something in the javascript layer to get it to be updated as well, so the entire structure can be re-bound to a YUI component.

      As a first pass we might be able to pass these elements into jsfProps directly, ensuring the javascript changes as well. If this gets to be too large, a concept similar to the JSONBuilder class might be used to accumulate all the string changes into one long string which then we take a hash of to make it a reasonable size.

         
      1. after.JPG
        53 kB
      2. before.JPG
        57 kB

        Issue Links

          Activity

          Greg Dick created issue -
          Greg Dick made changes -
          Field Original Value New Value
          Salesforce Case []
          Description I've noticed this issue on the LinkButton, but it should manifest in all ACE components under the right circumstances.

          The HTML structure built by the renderer encapsulating a LinkButton looks like this:

          <div>
            <span id="xxx_span" >
               <span class="first-child">
                   <a> A child node </a>
               </span>
            </span>
            <span id="xxx_script">
              <script> Yadda </script>
            </span>
          </div>

          The problem occurs when there is some behaviour that changes the markup in the span with the id "xxx_span", "first-child", or the anchor tag. The reason is that our dom-diffing algorithm finds the first parent element with an id and applies an update to that element. This excludes the javascript span and the <script> element is not reevaluated by the client.

          In the case of LinkButton, this causes the YUI component that was created on the initial update to be replaced with simple html. This manifests most visibly inwhen the linkButton value attribute is replaced on the link with the normal html value of: "A child node", in the above case.

          The component renderer is going to need to keep track of elements and attributes which are on the innermost elements of a nested component structure, and if they change, going to have to write something in the javascript layer to get it to be updated as well, so the entire structure can be re-bound to a YUI component.

          As a first pass we might be able to pass these elements into jsfProps directly, ensuring the javascript changes as well. If this gets to be too large, a concept similar to the JSONBuilder class might be used to accumulate all the string changes into one long string which then we take a hash of to make it a reasonable size.

             
          I've noticed this issue on the LinkButton, but it should manifest in all ACE components under the right circumstances.

          The HTML structure built by the renderer encapsulating a LinkButton looks like this:

          <div>
            <span id="xxx_span" >
               <span class="first-child">
                   <a> A child node </a>
               </span>
            </span>
            <span id="xxx_script">
              <script> Yadda </script>
            </span>
          </div>

          The problem occurs when there is some behaviour that changes the markup in the span with the id "xxx_span", "first-child", or the anchor tag. The reason is that our dom-diffing algorithm finds the first parent element with an id and applies an update to that element. This excludes the javascript span and the <script> element is not reevaluated by the client.

          In the case of LinkButton, my test page changes the style string on one of the inner spans of the anchor hierarchy. It's necessary to change the style on this level or it wont override the default Sam or Rime styling, and this sends an update of just the inner <span> tags which causes the YUI component that was created on the initial update to be replaced with simple html since the initialize method in the javascript is not re-executed. This manifests most visibly when the linkButton value attribute is replaced on the link with the normal html value of: "A child node", in the above case.

          The component renderer is going to need to keep track of elements and attributes which are on the innermost elements of a nested component structure, and if they change, going to have to write something in the javascript layer to get it to be updated as well, so the entire structure can be re-bound to a YUI component.

          As a first pass we might be able to pass these elements into jsfProps directly, ensuring the javascript changes as well. If this gets to be too large, a concept similar to the JSONBuilder class might be used to accumulate all the string changes into one long string which then we take a hash of to make it a reasonable size.

             
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.0.0 [ 10230 ]
          Assignee Priority P1
          Assignee Greg Dick [ greg.dick ]
          Greg Dick made changes -
          Attachment before.JPG [ 12747 ]
          Attachment after.JPG [ 12748 ]
          Greg Dick made changes -
          Link This issue depends on ICE-6418 [ ICE-6418 ]
          Greg Dick made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Assignee Priority P1

            People

            • Assignee:
              Greg Dick
              Reporter:
              Greg Dick
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: