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