You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Ann Priestman (JIRA)" <ji...@apache.org> on 2018/07/27 18:22:00 UTC

[jira] [Created] (NETBEANS-1082) Children.keys lazy parameter frequently has no effect

Ann Priestman created NETBEANS-1082:
---------------------------------------

             Summary: Children.keys lazy parameter frequently has no effect
                 Key: NETBEANS-1082
                 URL: https://issues.apache.org/jira/browse/NETBEANS-1082
             Project: NetBeans
          Issue Type: Bug
            Reporter: Ann Priestman


We've been trying to use lazy loading of nodes for an OutlineView. For testing we basically have a TopComponent that contains an OutlineView and uses the ExplorerManager, and then a class that extends Children.Keys, and we're looking at when/how many times createNodes() is called. Our expectation was that it will only be called for the nodes that are visible on screen (say, 50 of the 200 total nodes) but it appears to create all of them to start. We saw similar behavior with ListView and TreeTableView. Only BeanTreeView worked as expected - we saw it create 50 nodes to start and create more as we scrolled around the table.

It appears that in the other View types, all of the nodes are created from EntrySupportLazy.fireSubNodesChangeIdx(). For example, in our Outline view it looks like all of the nodes are created in this call to e.getChildren() from the EventBroadcaster listener:
{code}
/** Creates an identical TreeModelEvent with the model we are proxying
 * as the event source */
private TreeModelEvent translateEvent (TreeModelEvent e) {
 //Create a new TreeModelEvent with us as the source
 TreeModelEvent nue = new TreeModelEvent (getModel(), e.getPath(), 
 e.getChildIndices(), e.getChildren());
 return nue;
}
{code}

I believe there are points after this that would also lead to the nodes being created. 

We see that the Children.keys constructor documentation says "Constructor for optional "lazy behavoir" (tries to avoid computation of nodes if possible)." so it's not guaranteed, but we're still surprised that it seems to work in so few cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists