0

Selectable tree models are no longer generic

asked 2011-10-25 08:54:38 +0800

cvarona gravatar image cvarona
554 1 6

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());
    }
    ...
}

This amounts to saying the only functional selectable tree models will be those comprised of TreeNodes. However, the javadoc for TreeNode states it's meant to be used in conjunction with DefaultTreeModel. Thus other tree models holding values other than TreeNode instances cannot profit from the Selectable mechanism. In order for it to be truly generic and work for any kind of tree model the code above should read, I think, sltb.addSelection(item.getValue()).

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

delete flag offensive retag edit

3 Replies

Sort by » oldest newest

answered 2011-10-27 20:38:54 +0800

jimmyshiau gravatar image jimmyshiau
4921 5
http://www.zkoss.org/ ZK Team

updated 2011-10-27 20:40:32 +0800

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.

link publish delete flag offensive edit

answered 2011-10-28 03:26:54 +0800

cvarona gravatar image cvarona
554 1 6

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

link publish delete flag offensive edit

answered 2011-10-30 20:15:47 +0800

jimmyshiau gravatar image jimmyshiau
4921 5
http://www.zkoss.org/ ZK Team

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.

link publish delete flag offensive edit
Your reply
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

[hide preview]

Question tools

Follow

RSS

Stats

Asked: 2011-10-25 08:54:38 +0800

Seen: 292 times

Last updated: Oct 30 '11

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More