TreeView implementation loads not really on demand


Looking at the menu I found the following issue:
The tree is supposed to load the child nodes of a parent node on demand. The code for this is utilized in the JS files and the Home Controller. However, the menu provider loads all nodes recursively. GetMenuRoot calls GetChildren which will call GetChildren for every item, such creating a recursion. This is not a big problem with small structures but takes some time if the tree is used for something different than the menu.
My workaround:
I introducted a nullable boolean to ITVDataItem to idicate where a Node has children or not. In TVNodeRow and TVNode I chaeck if the property is set (hence the nullable). If that is the case, I use the flag to determine what kind of buttons to show, etc. If the flag is null, I use the "old" logic which means checking the Items collection.
Probably not the best solution but it worked for me.
A problem with loading the nodes on demand occures, when the page is reloaded (F5). In this case, the nodes that have been loaded on demand do not exist. Only the root nodes are present. The TreeView Control expects the child nodes to be present. I solved this, in storing the expanded nodes into the session and reloding all child nodes of the expanded nodes during a postback. I don't like having to store them my self because the tree already does this, but I haven't found a way to access that collection of expanded nodes.
Closed Nov 18, 2009 at 5:46 AM by Radim
Menu is based on the Menu.config 'Cached' in the memory.For this purposes is such solution probalby the best.For other cases, there could be implemented smart assingment based on the OOP, Entities and NHibernate.If some Entity has mapped collection for Children in the NHhibernate - the method for root can pass only root Entities-collection, the GetNode can pass only the just 'Expanded' Entity. If any child element is accessed (via .NET property getters) the NHibernate will ask SQL for the next data supply. There could be also some Caching for repeatedly created TreeViewes.(Maybe some example in the future...)


Radim wrote Sep 2, 2009 at 6:00 AM

Great job.
It looks good, and maybe it could be assembled as a choice in the basic release.
From my exeprience - even thousands of nodes in the RAM of the IIS is not a problem. In fact - this structure is loaded only once and than reused for any request. Even with a very large TreeView source - e.g. 10 000 rows the result won't ever overflow 10MB of RAM.
If there will be such a large structure, then the performnace (having 10MB in memory) or re-reading such a huge file (I can prove it from experience !!!) for every node (it means parsing it from the beginning) is 100x times slower.
If I'll have a time, I will create an example based on these big structures.

Simply - it is always good to have more approaches to decide!!!
Experience have proven the fact - XML files converted into XDocument - stored in the Application cache only ONCE - has 100x times better performance then re-reading it for every single node (which in the end leads to larger memory usage!)

benno wrote Sep 2, 2009 at 7:39 AM

My tree structure data contains round about 60.000 nodes. You are right, it is quite fast to load them. In my (special) case it is not static though and comes from a proprietary data source which is not very fast in providing the data. In addition the tree has to be loaded based on which item I edit. So in my case loading on demand seems to be the better way. I agree, it's good to have the choice. In the menu tree view it wouldn't make sense att all to load the nodes on demand.
BTW: that could be probably improved: even though all nodes are present, the Ajax callback / controller action still reloads all the nodes from the xml. But its blazing fast anyway....

wrote Nov 18, 2009 at 5:46 AM

wrote Feb 14, 2013 at 12:26 AM

wrote May 16, 2013 at 6:07 AM