PDA

View Full Version : TreeNode states need improvement



dfenwick
3 Apr 2007, 1:52 PM
TreeNode objects can currently either be a folder or a leaf. Unfortunately this isn't quite right. If one tags a node as a leaf the library believes that it's unable to have children (it's neutered!) Tagging it as a folder always applies an expand elbow graphic to it, which has no effect if it's the end of the tree.

Why would you want to have a folder be at the end of the tree? There's no reason for them not to be. Folders are containers. As such, there's no reason they shouldn't be able to be at the end of the tree. But they are not leaves. While it doesn't actually break drag and drop, the visual presentation is such that it just looks wrong because they have expanders that don't do anything.

Somehow this needs to get worked out. I propose somehow exposing hasChildren to the underlying expansion mechanism to determine whether or not a node marked as a folder actually has children, and only then show the expander + item.

jack.slocum
3 Apr 2007, 5:00 PM
I take it this is with an AsyncTreeNode? My question would be, how can it know that there are no children without making a request or you providing the information? And how can it trigger that request without a + icon or preset expansion?

There is a workaround available that does the behavior you want. There a thread in the beta detailing how to do it. I can look it up for you if you want. It's very simple and I am using it myself in the bug tracker. It consists of passing an empty children array (it has no children) and expanded:true (to kill the expansion indicator). It results in no additional server requests.

JeffHowden
4 Apr 2007, 9:49 AM
There is a workaround available that does the behavior you want. There a thread in the beta detailing how to do it. I can look it up for you if you want. It's very simple and I am using it myself in the bug tracker. It consists of passing an empty children array (it has no children) and expanded:true (to kill the expansion indicator). It results in no additional server requests.

I am, in fact, using that approach in my trees that use asynctreenodes and it yields excellent results. Not only is the UI more consistent, but it loads much faster too when doing an expandAll() on the tree because it doesn't require any trips to the server for leaf nodes that don't have children.