There are two options that I can see here. One option is to read the entire tree into memory (on startup?) and then just access levels of it for each tree expansion request. As you said, this might not be an option if the tree is large.
The other option is to lazily get each level from the database via the ajax requests when a user expands a node. I'm looking at the tree API (TreeModel and TreeModelAdapter) and if you are not careful, there is the possibility that you will face the n+1 selects problem (it's actually a 2n+1 selects problem) when getting a node's children and determining isLeaf() and hasChildren() for each of them. I'm pretty sure that setting up a parent / child relationship in hibernate and using lazy loading will help here but if you were using straight JDBC you would have the problem. I'm currently (between doing real work) testing an adapter that uses a (dirty) thread local to adapt a TreeModelAdapter to a more database friendly interface. By more database friendly I mean that all of the isLeaf() and hasChildren() calls are done in single queries. Therefore requiring 3 queries instead of 2n+1 to determine a nodes children and isLeaf() and hasChildren() for each child. On Wednesday, 8 February 2012, tgupta1419 <tgu...@yahoo.com> wrote: > For getting a tree and if there are thousands of nodes - wouldn't it be a > problem getting all the nodes in the memory and then processing it. > > -- > View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-TreeGrid-tp5462126p5467951.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
