-
FEATURED COMPONENTS
First time here? Check out the FAQ!
Hi there,
I've come across the following problem:
public void selectItem(Treeitem item) { ... if (_model instanceof Selectable) { // B50-ZK-306: DefaultTreeModel does not properly // synchronize deselection state -- // _model should clear at first too Selectable sltb = ((Selectable) _model); sltb.clearSelection(); sltb.addSelection(item.getTreeNode()); } ... }
Any clue about this subject? Is it actually a bug, or should I rather assume that TreeNode should be the content of any TreeModel implementation (and thus it's the javadoc that neglects to making it clear)?
With kind regards
César Varona
Hi César,
The treeModel is a collection of treeNode,
>>>other tree models holding values other than TreeNode instances cannot profit from the Selectable mechanism.
so you implement a treeModel and not collect the treeNodes
about generic, it will available in ZK6.
Hi Jimmy,
I quote the TreeNode's javadoc:
Defines the requirements for a tree node object that can change -- by adding or removing child nodes, or by changing the contents of an application-specific data (setData(java.lang.Object)) stored in the node. It is designed to be used with DefaultTreeModel.
For a common reader this means: "default tree models (i.e., instances of DefaultTreeModel) will be comprised of TreeNodes, other tree models won't". In other words,
tree models freely implemented *might* contain values other than TreeNodes. The zul api actually allows for it, and I've done it so myself. No problem so far.
But alas, free tree model implementations will surely want to profit from the "Selectable" mechanism. In order to do so, the Tree component should be able to transfer
the value corresponding the selected tree item(s) (which of course won't be a TreeNode instance) to the selection in the model. It's no way like this right now, for it's not
the tree item's value that it transfers, but the "TreeNode" it contains. This amount to saying that
1) The Treeitem implementation is heavily tied to TreeNode and thus to DefaultTreeNode
2) Only those tree models containing TreeNode instances will be Selectable
I'm afraid I do not understand you very well when you say:
>> so you implement a treeModel and not collect the treeNodes
What do you mean by "collect the treeNodes" and how it would 1) prevent the tree component from trying to transfer the TreeNode the Treeitem *might* contain and
2) make the tree component transfer the values my tree model works with instead? To the best of my knowledge, the TreeNode transfer is hardcoded and there is no
way to circumvent it. I could, of course, write a TreeNode subclass and set it up. It would be a minor nuance, but if I do so, won't the tree component then handle my
tree model as if were a DefaultTreeModel (something I don't wish by any means: in my environtment it's the TreeModel that owns the knowledge of what nodes are
children to which parents, and not the nodes themselves).
I don't think tree models should compulsorily comprised of TreeNodes the way they're designed (it might be not always possible to do so, or just difficult), but, if it's
so, the documentation should state it very clearly.
So by "generic tree model" I mean a tree model which can contain values other than TreeNodes, and not a TreeModel using java5 generics.
With kind regards
César Varona
Because tree is a level structure, we need a object can present the structure, if user use a free tree model without tree node, we cannot expect how the user to present the structure.
Asked: 2011-10-25 08:54:38 +0800
Seen: 292 times
Last updated: Oct 30 '11