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
