Forums

I'd like to follow up with some updates first:
1. Gonzalo has moved on and he's no longer the official owner of TreeView. I am. Bear with me as I get on board and flex my neurons.
2. The TreeView was in a special PR release and hasn't been committed to master because we wanted to have more discussions and collect additional feedback. After gathering all the information, we have decided that it would be best to keep TreeView out of core for the 3.6 release. I will take it over as a gallery contribution, and continue working on it as a beta module there, with an understanding that in the future TreeView can become part of the core.

Brett -- great feedback. I would put the priority order on it as follows: (1) proper rich markup (more of a bug fix), (2) detailed events for all aspects of TreeView changes / interactions (also a bug fix), and (3) dynamic data loading. I'll put these at the top of my list for the next set of features to implement for the TreeView.

Satyam, per your posts, it appears that, aside from clearly fixable problems like improper markup and lack of sugar methods, you primarily take issue with the fact that there is an unnecessary differentiation among different type of subtrees (TreeLeafs vs. TreeViews). Is that a fair summary of your position? Beyond a semantic difference, what problems does such a differentiation cause? If the lazy rendering is properly implemented, is there still an issue with memory consumption? Additionally, let's not get into what's lacking in the TreeView right now -- that's a discussion for the 3.7.0 timeframe when I actually start building up the TreeView (so, for example, details on how to render from markup will be useful to think about at that point, but not right now).

@Allen,

Yes, the core of my complain is the TreeView/TreeLeaf separation. It is my objection now as it was a year and a half ago when I first said so. There are just two kind of objects in a tree, the object representing the tree as a whole and its root and then another object representing each and every node in the tree, which might have 0 or more children.

You can only break it into TreeView/TreeLeaf it you don't go beyond the most trivial examples where it doesn't really matter. Once you start adding all the methods and attributes that TreeView (the root) requires, then you start finding out that those features make no sense at the non-root level. At the other end, a node with or without children doesn't behave so different so it turns out it makes no sense differentiating in between leaf and non-leaf nodes.

Once we agree on that, then we can start talking about markup, features and enhancements, but if the basic architecture is failed, then there is no point in trying to fix it. If you design a car with the wheels on the roof, it doesn't make sense to talk about whether to put leather seats on it or not.

I'm happy the component has been delayed until 3.7.

I wonder what happened to all the tickets filed for YUI2 TreeView. There are just two tickets left in the database. That would have been a great source of information about what users needed. I have a copy of them in my email client, even the ones coming from the old YUI Trac system and, anyway, I remember the most crucial ones since I handled them (a part of my particular history of my involvement with the YUI library that is now wiped out), or at least I remember those that were the worst headaches.

Anyway, I don't know how bad it was to have all those YUI2 tickets in there but for components that existed in YUI2 and not yet in YUI3, as TreeView, and even those that do exist (after all, there is a lot of people using them out there) there was a lot of valuable information there. For a situation like this, having a list of all the feature requests would have been a good basis.

This is something the source code cannot provide as it is mostly very old code with every new feature placed on top of it with the utmost care to keep it backward compatible. The users guide and the API docs are a good reference, though. At least they show the features of it without showing the internals which might be quite disgusting if you look into them. The basic markup, all those one-row tables, one per node, was awful, but couldn't be touched. At a time when most components were subclasses of Element, TreeView couldn't be changed to use it.

However, it is still up and running, quite a feat!

A proposal:

All this discussion made me think about doing a couple of base objects: a flyweight manager extension and a flyweight node. There was another thread in the forum (viewtopic.php?f=92&t=10329&p=33732#p33732) that made me realize that there could be three components that could benefit from this:
* TreeView
* Menu
* Form

They all have an overall container and have a tree-like structure (forms have fields but also grouping elements such as fieldsets) and potentially many nodes, which should be lightweight. They also have a very interesting characteristic in that the focus of the component is usually set at a single child at a time (the form field with the focus, the TreeNode or MenuItem just clicked), thus, there is rarely any need to have instances of all nodes active at any one time, thus, they can all be pooled and managed by the flyweight manager.

The flyweight manager extension could be used to extend Widget which would make the main container for the whole component. It would accept a configuration object or a Dom Node reference or CSS selector to produce such a configuration object from the markup. It would make a clone of this object and keep it as the basis for the nodes in the component.

The extension would provide the methods to traverse this configuration object and slide the node instances on top of each. It would keep a pool of node instances by node type which would reuse to slide on top of the active node.

The extension would be the receptor of all events produced by the nodes, either DOM events capture via delegation or custom events fired by the node instances where the flyweightNode object would delegate (via EventTarget.addTarget method) to it. The extension would be responsible to locate the actual node and slide an instance for the corresponding node type on top of the node to pass as part of the event facade for such events.

The flyweight node instances would be based on BaseCore and would contain a private _node property which would be set by the flyweight manager to point to the node it has been slid over. Most attributes would access their values via this._node. flyweight nodes would have a few common attributes which do not come from this._node:
* depth (how far in the tree structure they are),
* index (its position within the array of children)
* root (a reference to the form, treeview or menu bar, that is, the widget extended via flyweight manager)
I am not including the children attribute in this list because that one is accessed via this._node just as the rest.

flyweight nodes would have a render method and a template attribute. The render method would use, in that order, its own template attribute or the static template for the whole node type or the default child template at the root. The default renderer would use Y.substitute with the template string and a reference to this._node as the source of values. A configuration attribute should be available to switch from this fast renderer to one which uses this.getAttrs instead of this._node as the second argument to Y.substitute. This would be needed for the few that need access to other calculated attributes such as depth or index, which are not available in this._node.

The flyweight manager extension would provide generic node traversal methods such as forEach, forEachByXXXX, which each of the derived classes might further supplement with extras such as forEachExpanded, forEachSelected, in the case of TreeView or forEachField (skipping over fieldsets and other containers, in the case of Form).

The flyweight nodes would have slideToNext, slideToPrevious, slideToParent, slideToFirstChild which would ask the flyweight manager to slide itself on top of the appropriate node (I called them moveTo on a previous post, but I think SlideTo is better suited). Those methods would return a boolean indicating success and this._node would be set to null in case of failure: early crashes help debugging. Nodes would also have forEachChildren methods.

If the developer wants to keep a reference to a particular node, both the root and the children would need to offer a variety of getNodeBy methods which would return a non-reusable instance of a node, permanently pointing to the given node. Such instances might be taken from the pool but never returned to it so it is never slid upon any other node so the reference given to the developer remains valid.

As it turns out, all these three, TreeView, Menu and Form do have even more in common than I thought. It is obvious that TreeView and Menu have expanded and collapsed states, but I just realized Forms might as well, as large forms are often broken into collapsible panels. Whether they are shown accordion-style, tabview style or multi-page wizard, which is only a matter of defining which grouping control to use besides the standard fieldset, nodes on forms (grouping ones in this case) can also be collapsed or expanded just as those of a tree.

Since all of these have expanded/collapsed states, it is obvious that lazy rendering comes naturally to them. When navigating through its nodes, the flyweight manager should check their expanded state and visit their children only if it is true.

The configuration object, which serves as the basis to build the tree and whose nodes are the ones the flyweight nodes slide over, would have a rendered property which would tell them whether they have already been rendered or not.

The render method of each node would return a string which would be concatenated with those of its siblings and placed wherever is suitable in the parent. Such string would then go all the way up to the root object to be inserted in the innerHTML of its contentBox. Should there be any post-render DOM Node formatters to process, the flyweight manager would traverse the configuration object to see which nodes need that extra step and slide a node instance of the appropriate type on top of it to handle it.

And, BTW, I know there is already a Menu component and no plans for a Form component, I just list them to show the range of applications this flyweight manager extension/flyweight node can have. An accordion might also fall into this pattern, even if accordions naturally have a depth of 2 and only one child per branch, the first for the title bars, the second for the content. The same with TabView, one level for the tabs, a second for the panels.

Anyway, my point is, this mechanism provides for lazy rendering (only the visible nodes get rendered, you don't bother to render nodes with the display:none CSS attribute) and it has a minimum of node instantiations. My guess is that the pool of node instances for a tree would not be proportional to the number of tree nodes (or menu items) in it but to the depth of the tree and, in most cases just as deep as the deepest node ever rendered (assuming all nodes are of the same type). Anyway, the number of nodes on the pool should be configurable and if the pool is already at that level, the freed node would be simply dumped instead of pushed back into the pool. This does not count the node instances the developer has specifically requested via one of the getNodeXxxx methods since those are not in the pool.

I thought that was a little gloomy