My favorites | Sign in
Project Home Downloads
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 18: Option to control caching of lazy nodes
1 person starred this issue and may be notified of changes. Back to list
Status:  Verified
Owner:  moo...@wwwendt.de
Closed:  Oct 2010


 
Project Member Reported by moo...@wwwendt.de, Aug 30, 2008
tree.options.cacheLazyNodes = true

Can be set to false, so that collapsing and re-expanding will reload it.
Aug 30, 2008
Project Member #1 moo...@wwwendt.de
If caching is off, we could *delete* all child <elements> to free up memory when a
parent is collapsed.
Aug 30, 2008
Project Member #2 moo...@wwwendt.de
(No comment was entered for this change.)
Labels: Milestone-Release0.3
Aug 31, 2008
Project Member #3 moo...@wwwendt.de
(No comment was entered for this change.)
Labels: Milestone-Release0.4
Feb 2, 2009
Project Member #4 moo...@wwwendt.de
(No comment was entered for this change.)
Labels: Milestone-Discussion
Oct 17, 2010
#5 prana001
Is this enhancement still in effect/under development?
Because I think it'll add to DynaTree.

I've noticed that when you really "walk" the tree: imagine a folder scan, 4 levels deep, that browsing gets slow after some browsing.
At a certain point, each Lazy subfolder that's clicked, will add a couple of ms. overall waiting time to the process.
You can notice this because the loading indicator stays on screen bit longer.

Now.. similar to a "messy desktop": you start closing stuff to clean it up.
Same thing people do with DynaTree: they start closing all the subfolders they don't want to see/need at that point, assuming browsing will go faster again, because they don't see the all the subfolders. :)

Ofcourse the culprit is the creation of dom nodes, elements etc.

Thus.. YES, if (lazy) subfolder were to be closed, delete them from memory
immediately, or whip up some kind of caching system.
However since JSON retrieves data rather fast, this should not really
be a problem? 

It will probably also cut back in waiting when the whole tree gets .destroyed()
The bigger the tree, the more ms. one has to wait.
Oct 17, 2010
Project Member #6 moo...@wwwendt.de
I haven't tried, but it should be possible to do achieve this by implementing a callback handler:

    onExpand(flag, node)
        if(!flag)
            node.remveChildren()    
Status: Waiting
Oct 31, 2010
#7 prana001
Yes! Works beautifully, thanks!
Oct 31, 2010
Project Member #8 moo...@wwwendt.de
(No comment was entered for this change.)
Status: Fixed
Jul 17, 2012
Project Member #9 moo...@wwwendt.de
considered verified
Status: Verified

Powered by Google Project Hosting