[
https://issues.apache.org/jira/browse/WICKET-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735745#action_12735745
]
Matej Knopp commented on WICKET-1600:
-------------------------------------
But we only update portions that have actually changed (even though we need to
send entire rows). The problem is that there is lot of generated markup for
each row. Only way around here would be to send tree data and build the markup
on client. But that would mean you can't put wicket components in nodes.
Also the swing TreeModel is not very nice interface but it does it's job. It's
much better now in wicket then it was since i was able to get rid of TreeNode -
so now any object can be a node.
And for simple implementation all you need is to implement 5 simple methods if
you want to build it from scratch. Tracking changes is bit more difficult but
if you look like TreeModelListener it does look pretty sane. Even though
probably more complex as it need to be for our needs.
However we need to be able to track changes to model to be able to do partial
updates. Partial updates are the key point of wicket's AbstractTree. For 1.5 it
would be nice to get rid of the swing classes simplifying the model, but only
if we can build an adapter so that swing tree model can still be used.
> Wicket tree improvement
> -----------------------
>
> Key: WICKET-1600
> URL: https://issues.apache.org/jira/browse/WICKET-1600
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4-M1
> Reporter: Sven Meier
> Assignee: Matej Knopp
> Priority: Minor
> Fix For: 1.5-M1
>
> Attachments: tree.diff
>
>
> I see the following issues with Wicket's tree implementation that should be
> solved:
> AbstractTree and its subclasses were written with the Swing JTree API in
> mind. This is not a bad thing per se, but the JTree abstractions are not very
> well suited for a web application. Matej recently removed some of these
> dependencies, but there's still a lot of code that uses TreeNode,
> TreeModelEvent and such.
> AbstractTree holds a TreeModel in its model, attaching a listener to it. This
> is an unusual approach for a Wicket component:
> - It implies that changes in the TreeModel are automatically propagated to
> the user interface. This is not always the case, as in an ajax request the
> AbstractTree has to be explicitely notified to update itself.
> - It requires the AbstractTree to monitor the model for a replaced TreeModel.
> Most importantly the TreeModel API is complicated and ambiguous (just see the
> javadoc of TreeModelEvent and TreeModelListener) which makes life harder
> especially for those who want to use AbstractTree with their own TreeModel
> implementation (which is difficult enough). Although not directly visible in
> the API, an implementor has to privide the parent of a node - see
> AbstractTree#getParentNode(). Tree listeners and events are an annoyance
> which doesn't match Wicket's elegance.
> Currently many components in the AbstractTree hierarchy hold a reference to
> real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a
> foreign concept to Wicket, holding references to nodes too. To support
> detachment AbstractTree tests wether a node implements IDetachable,
> effectively duplicating functionality that is normally provider by Component
> and its model out of the box.
> The nodes are currently used to identify state (e.g. the parent) in the tree.
> To add a node, the nodes have to implement equals() and hashCode() to be
> correctly identified in the tree state. This might be unacceptable, e.g. if
> entities (business objects) are used as nodes, probably loaded from a
> database.
> Therefore I propose to refactor AbstractTree and subclasses as follows:
> A new interface INodeProvider (similar to IDataProvider) defines a concise
> API to define a tree of nodes. The method #model(Object) gives an implementor
> the possibility to wrap nodes in a suitable model, e.g. a detachable one. The
> provided model can handle #equal() and #hashcode() for identification of
> nodes in the tree.
> References to nodes are always indirect through the model, never to the real
> node object.
> Handling of node parents is completely managed inside AbstractTree, no need
> for an ExtendedTreeModel.
> The model of an AbstractTree is used for node selection, similar to
> AbstractChoices.
> Listeners are replaced with notification methods on AbstractTree. No need for
> tree paths on changes.
> Expansion state is held in the AbstracTree#TreeItems (instead of former
> ITreeState) - similar to component visibility.
> The attached patch tries to achieve all this (or at least show how a solution
> could look like), additionally:
> - AbstractTree now utilizes AbstractRepeater and
> #setOutputMarkupPlaceholderTag() instead of custom solutions.
> - The examples are modified and enhanced with 'add' and 'remove'
> functionality, org.apache.wicket.examples.nested.Home shows usage of an Swing
> TreeModel adapter.
> - Lots of generics are added (Swing's TreeModel will probably never be
> generic).
> - The code is (hopefully) simplified.
> I apologies for putting all this stuff into a single patch, but I wasn't able
> to split these issues apart - it all depends on the proposed INodeProvider
> interface.
> For users of AbstractTree this solution has the following impacts:
> - minor API changes for subclasses
> - if a node is collapsed, all state of descendants will be lost, i.e. if the
> node is expanded once again, all previously expanded children will stay
> collapsed (similar to how Gnome handles trees)
> - optimization for adding multiple new children in one AJAX request is not
> (yet) supported, this was part of the former custom markup handling.
> I will continue working on AbstractTree with tests and documentation. But
> before doing that, I'd like to get a feedback from wicket committers
> (especially Matej), if this proposed solution matches their conception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
