Great you dropped this oddity!
Makes lots of wicket users much happier.... :-)
Am 01.05.2008 um 12:57 schrieb Matej Knopp:
Hi,
while TreeModel is not perfect, there are practical reasons for using
this interface. In future I plan to replace it with something much
cleaner with well defined non-ambiguous methods. But at the same time,
we will need an adapter to use existing TreeModel's with the new
model.
On Thu, May 1, 2008 at 10:26 AM, Sven Meier <[EMAIL PROTECTED]> wrote:
Hi Matej,
I'm glad to see that you've put some work into AbstractTree lately.
The
previous dependency on TreeNode (Wicket-1555) was an annoyance.
IMHO we could improve things further, if we dropped usage of
TreeModel.
This interface is one of the poor designed concepts in Swing and
we're not
even using it completely:
#isLeaf()
Its meaning is ambiguous, we can just use getChildCount() to see
wether the
junction link should be functional. Other than that it is only
relevant for
display purposes (using a folder or file type icon), why should
this method
be part of a model interface?
#valueForPathChanged()
this method is never called in Wicket (and was always a hassle to
be used
in Swing anyway)
#getIndexOfChild()
never used in Wicket
#addTreeModelListener() and #removeTreeModelListener()
IMHO this listener concept is foreign to Wicket. On a normal
request we
could just re-evaluate the complete tree.
For AjaxRequest you have to call updateTree() anyway, why not just
add some
notification methods to AbstractTree and get over with
TreeModelEvent (and
TreePaths while we're at it)?
I don't agree with this at all. The treemodel listener makes lot of
sense. If the model behaves nicely and notifies the listeners when
nodes are added/removed/changed wicket tree is able to update only the
changed portions of tree during ajax request without redrawing the
whole tree. This is a major performance improvement with big trees.
Or we could even introduce a callback, e.g:
tree.updateTree(ajaxRequest, new AbstractTree.Change() {
public void inAjax(AjaxChange change) {
change.nodeChanged(...);
change.nodeRemoved(...);
change.nodeAdded(...);
change.expandNode(...);
...
}
});
This would couple the model changes with the actual tree components, I
don't see any reasons for this. If you write your model well it will
notify the listeners properly and still has zero dependency on the
actual tree component. I just don't see any reason for changing this.
I don't say the listeners as they are now in swing's TreeModel are
pretty or very easy to use, but they work. So while I'd like to
replace it with something simpler and easier to use, I'm not willing
to sacrifice any of the functionality.
What I'd really love to see is a new interface similar to
IDataProvider
replacing TreeModel - perhaps INodeProvider??
An additional method INodeProvider#model(T) would be very handy. The
created model could ...
- handle detachment - currently a check "modelObject instanceof
IDetachable" is used in TreeItem.
- control equality - currently this is the duty of the nodeObject,
as they
are held as keys in nodeToItemMap.
I'd happy to contribute patches, but I'd like to hear your opinion
on these
suggestions first.
Currently the node objects can implement IDetachable. That's natural
thing to do. We could have an interface that treemodel would implement
to allow custom model around the treenode, but i'm not sure what the
benefit would be.
-Matej
Sven
--
Resizable and reorderable grid components.
http://www.inmethod.com
