ICEfaces
  1. ICEfaces
  2. ICE-5706

ice:tree dom-diff optimised structure

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.8.2-EE-GA_P01, 1.8.2a
    • Fix Version/s: None
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      All

      Description

      Have an example application with thousands of nodes in a tree. Actually 4 trees, parallel to each other, creating the impression of a tree table, with each tree being a different column. The leftmost tree has drag and drop setup on each node, as well as a context menu.

      Optimisations in ICE-5704 bring the performance of most operations up to snuff. The only place left where performance falls off a cliff is when moving a node from/to the tree root. Similarly, adding or removing a node from the root. This is because the root element's child count changes, so the whole root and all its children, and so the whole tree, is resent to the browser.

      The question is how to reduce the dom diff when a child node is inserted and/or removed, to minimise the sibling, and sibling's child hierarchy, sent to the browser. Taking a cue from the TBODY technique from ICE-3310, a solution could be to create groupings of children, within DOM elements with ids, so that if one child is inserted or removed, only that group of children would be resent, instead of all children. That would require the remaining nodes to maintain affinity to their clientIds, as well as their group. Inserted nodes would require clientIds that do not clash with the pre-existing ones.

      For the clientIds, a permanent node identifier would seem to be better than the position dependent scheme currently in use.

        Activity

        Hide
        Mark Collette added a comment -

        The code still has unresolved issues, so it's not ready for trunk. Further developing it is out of scope for our current 1.8.2 EE release. The code should be moved either into the jira via a patch, or into a subversion branch.

        Show
        Mark Collette added a comment - The code still has unresolved issues, so it's not ready for trunk. Further developing it is out of scope for our current 1.8.2 EE release. The code should be moved either into the jira via a patch, or into a subversion branch.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mark Collette
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: