ChildPropertyTreeModel does not query all of the data at startup time. The question of how much data has to be loaded up front simply depends on what object is wrapped up by the ChildPropertyTreeModel. If that object is smart enough to only get children when that specific property is queried, then yes, it'll be lazy.
*However*, unless you override isContainer() and isContainerEmpty(), ChildPropertyTreeModel will be "one-deep" aggressive - it'll load children of the visible nodes as it tries to figure out whether it needs to draw expand-collapse icons. Override those two methods with something more efficient - for example, guessing that isContainerEmpty() is true until you've loaded the data and know for sure - will make it 100% lazy. Of course, you can implement a TreeModel from scratch if you want finer control. -- Adam On 1/8/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
Hi, I found on internet that the above topic is a bit contraddictory, so I'm trying to clarify here. On one side - I saw a statement about this class not being suitable for lazy loading - since it requires all data to be available at construction time. However from sources it appears that deep node data are required at runtime, so that lazy loading should be natural, occurring whenever the component asks for children in getChildData (much like the Tomahawk tree2 component). Is that correct ? Did anybody succeed in building a lazy-loading tr:tree with native ChildPropertyTreeModel ? Thanks -- Renzo
