I considered - actually made a start - with making some stubs in order to loose the Swing dependency. But, it soon started to be a huge copy action of the Swing tree packages. Also, in my case (in company) it would definitively have advantages to be able to plug in a Swing tree model as we use them in other projects as well.
It's a pitty that there's no generic tree package in the JDK. There are classes for lists etc in java.util, but as the only good tree(nodes) available are in Swing, I think it is not completely absurd to use this. Actually, reversing your argument, say that I made some special purpose data structures for the trees in Wicket, why not for ListView and Table then? Wouldn't that be just as confusing?
Nah, the longer I think about it, the more confident I am that this (using part of Swing for data) is the way to go. So, unless I am convinced to rethink this, I guess I'll leave it like it is.
Next question is whether it should be in core or in contrib. I'll put out a vote for this.
Eelco
Jonathan Locke wrote:
sounds good.
it could be that we should put this in wicket-contrib until 1.1 so we can tweak it before people depend on it like a core component. there's so much going on in core (and life outside wicket!) that i'm afraid we won't give tree the review and refinement it deserves.
jon
Eelco Hillenius wrote:
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
