i was thinking:
it stays in contrib under a contrib namespace for 1.0, but gets copied to core namespace after 1.0 release and then is evolved for 1.1 release.
think of contrib as a sandbox (and sandbox namespace) for core.
we won't break anyone using the 1.0 contrib tree in 1.1 (because we'll abandon the contrib tree development in 1.1) AND we don't have commit to a core tree implementation for 1.0.
you don't have to agree with this... but am i at least making sense?
Johan Compagner wrote:
But if we move it to contrib then when 1.1 is released we suddenly have 2 exact same tree implementations? (if nothing is changed)
Or do we then move it out of contrib? But that will also break things for people that are building with wicket
Because in the end i think both jars are just dropped into a webapp. And developers just use both as they where one.
Or we should keep the same package and move it from contrib to wicket when it is done..
johan
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:
I was not that happy with the Swing dependency either, but the classes I use of Swing are so powerfull that I wouln't do without them as it would definitively mean less functionallity. I have looked at trees of other web frameworks as well, but they're really not that powerfull IMO.
What I think is absolutely great about the Swing tree, is that the model and view (tree state) are nicely seperated. This way, you can re-use your whole tree model for all clients, and use a tree state per client. I've used this in many projects, and allways thought it's one of the best pieces of Swing.
If people want to propose/ build Wicket specific replacements, that's fine. But I've put so much effort into it right now, that I want to give it a rest.
Eelco
Jonathan Locke wrote:
sounds cool.
i'm not sure i like the swing dependency though because it raises questions about why other components don't depend on swing and creates a kind of slippery slope... better to roughly modify/move that interface into our namespace i think.
Eelco Hillenius wrote:
Hi all,
I am done with the tree component(s). I can think of extensions, but I think it is really easy to use and quite extensible right now.
In the wicket.markup.html.tree package, there is one abstract class for trees, and two specializations of it. The two trees have a different rendering strategy, which have their own pros and cons.
One (wicket.markup.html.tree.Tree) renders nested <ul> and <li> tags, e.g.:
<ul id="nested">
<li id="row">
<span id="label">foo</span>
</li>
<ul id="nested">
<li id="row">
<span id="label">bar</span>
</li>
</ul>
<li id="row">
<span id="label">suck</span>
</li>
</ul>
The other (wicket.markup.html.tree.FlatTree) renderes single rows with spacer components, e.g.:
<span id="spacers"></span><span id=" spacers"></span><span id ="node"><span id="label">foo</span></span>
<span id="spacers"></span><span id ="node"><span id="label">bar</span></span>
Like I said, both have pros and cons, that's why I wanted to have both.
Currently you need to feed trees Swing's TreeModels with DefaultMutableTreeNodes. I might (or someone else) add support for nested lists sometime, though they will then be just converted to tree models with tree nodes.
I took me a long time to develop them, partially because I was not happy with the first versions. I am happy with these now, so I hereby propse them for Wicket 1.0. Look at the filebrowser example for examples of the different trees.
Hope you have fun with them,
Eelco
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- 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
------------------------------------------------------- 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
