You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Matej Knopp <ma...@gmail.com> on 2007/06/10 18:01:31 UTC
Wicket Trees Situation
Hi folks,
I hope this e-mail won't upset anyone too much.
Let me summarize our tree components situation first.
We have Tree and TreeTable components in core, and another Tree
component in extensions.
The Tree from extensions is the oldest one, without Ajax support.
The Tree in core (as well as TreeTable) supports Ajax, but
unfortunately suffers from layout problems and layout limitations,
such as fixed line height, no way to wrap tree text or no way to add
horizontal scrolling. Also the Tree is a bit difficult to customize.
Fortunately, the base class that encapsulates the hard work (tree
logic), AbstractTree, is pretty much presentation agnostic and it's
not a big problem to build another component on it which would solve
those layout problems.
In fact, I've already such component done. It supports variable
heights, content wrapping and horizontal scrolling. But the question
is, where (and maybe even if) should we put it?
The solution I want to propose may sound a bit radical. So I expected
people want to yell on me and/or want kick my ball.
Yet I'd like to
a) remove the old (kinda unsupported) tree from extensions (is
anyone even use it?)
b) move the current Tree and TreeTable* from core to extensions
(sight, i know we moved it into core just recently)
c) move the new Tree into core.
* I don't think it's a good idea to have a TreeTable in core anyway.
We don't have DataTable in core and I'm pretty sure much more people
are using DataTable then TreeTable.
So... I know it's kinda late for things like this. But i was way too
busy to do this sooner. Sorry.
-Matej
Re: Wicket Trees Situation
Posted by Eelco Hillenius <ee...@gmail.com>.
> Well, if I remember correctly the outcome of the discussion was
> DataView into core, DataTable stays in extensions.
Yeah, it was. But not because I wanted that :)
> Although I wouldn't mind DataTable in core.
> I think a Tree (the new one :) ) belongs to the core. But the
> TreeTable really can live in extensions. At least the one we now have
> (with layout problems).
Ok. Sounds good to me then.
Eelco
Re: Wicket Trees Situation
Posted by Matej Knopp <ma...@gmail.com>.
On 6/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > a) remove the old (kinda unsupported) tree from extensions (is
> > anyone even use it?)
>
> +1
Cool.
>
> > b) move the current Tree and TreeTable* from core to extensions
> > (sight, i know we moved it into core just recently)
>
> Don't know yet.
I'm pretty positive this would be a good move. Porting from 1.2 would
be non-issue, and if someone uses the trunk, you'll just have to
change the imports.
>
> > c) move the new Tree into core.
>
> So the 'new new' tree is incompatible with the 'new' tree? Why can't
> you just give them different names and let them live together in a
> package? One of the anoying things currently is that you have to ask
> people whether they are working with the core or extensions tree; I
> bet that's as confusing for users as it is for us. Imho, it would be
> better to just delete the old one and keep all the trees we're gonna
> support in core projects together in one package so that users can
> find them more easily and compare their features.
The new tree could be a drop-in replacement for the old one, as long
as you don't extend the old one's functionality. So rather then try to
be backwards compatible, which wouldn't work well anyway, i prefer
having the old one in extensions and new one in core.
As for the names, the new one probably won't be called a Tree. There
will be a LabelTree and a LinkTree, as well as BaseTree on which you
can override a method to provide node panel (which is much easier
customizable than what we current have - people have demanded this a
lot).
I don't want two different trees in core, that would just confuse
users. Having one (recommended) tree in core, and the old one in
extensions (so that we don't break people's code) is what I'd prefer.
>
> > * I don't think it's a good idea to have a TreeTable in core anyway.
> > We don't have DataTable in core and I'm pretty sure much more people
> > are using DataTable then TreeTable.
>
> If I remember correctly I argued for moving everything related to
> repeaters to core a while ago. The initial idea was always that
> extensions was either for components that you rarely use in a project,
> or for components that need to 'mature' a bit. I don't think the
> latter is a very good idea anymore (we could have wicket-stuff
> projects instead) and imho, any component that you'd almost always use
> in any project could go to the core project. Datatables definitively
> fall into that category. And trees... well it is still my opinion that
> they have a place in lots of projects. Core is fine with me.
>
> Eelco
Well, if I remember correctly the outcome of the discussion was
DataView into core, DataTable stays in extensions. Although I wouldn't
mind DataTable in core.
I think a Tree (the new one :) ) belongs to the core. But the
TreeTable really can live in extensions. At least the one we now have
(with layout problems).
-Matej
Re: Wicket Trees Situation
Posted by Eelco Hillenius <ee...@gmail.com>.
> a) remove the old (kinda unsupported) tree from extensions (is
> anyone even use it?)
+1
> b) move the current Tree and TreeTable* from core to extensions
> (sight, i know we moved it into core just recently)
Don't know yet.
> c) move the new Tree into core.
So the 'new new' tree is incompatible with the 'new' tree? Why can't
you just give them different names and let them live together in a
package? One of the anoying things currently is that you have to ask
people whether they are working with the core or extensions tree; I
bet that's as confusing for users as it is for us. Imho, it would be
better to just delete the old one and keep all the trees we're gonna
support in core projects together in one package so that users can
find them more easily and compare their features.
> * I don't think it's a good idea to have a TreeTable in core anyway.
> We don't have DataTable in core and I'm pretty sure much more people
> are using DataTable then TreeTable.
If I remember correctly I argued for moving everything related to
repeaters to core a while ago. The initial idea was always that
extensions was either for components that you rarely use in a project,
or for components that need to 'mature' a bit. I don't think the
latter is a very good idea anymore (we could have wicket-stuff
projects instead) and imho, any component that you'd almost always use
in any project could go to the core project. Datatables definitively
fall into that category. And trees... well it is still my opinion that
they have a place in lots of projects. Core is fine with me.
Eelco
Re: Wicket Trees Situation
Posted by Mats Norén <ma...@gmail.com>.
Is there any feature set available for the "new" treetable?
/Regards Mats
On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> Yes, exactly. That's what I want.
>
> -Matej
>
> On 6/10/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > So for the tree and treetable nothing changes with respect to wicket
> > 1.2? Both are in extensions, and a new tree replaces the old, pre ajax
> > tree?
> >
> > Martijn
> >
> > On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> > > I think it is much better.
> > >
> > > As for the TreeTable: The new TreeTable that I plan (without those
> > > neat lines but also without layout problems) is not alive yet. And the
> > > one that we already have should be moved back to extensions. I don't
> > > think we need (nor should have) TreeTable in core.
> > >
> > > -Matej
> > >
> > > On 6/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > if it is really better then do it now before we put out rcs. also what
> > > > happens to treetable? that should prob also move to extensions?
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > I hope this e-mail won't upset anyone too much.
> > > > >
> > > > > Let me summarize our tree components situation first.
> > > > >
> > > > > We have Tree and TreeTable components in core, and another Tree
> > > > > component in extensions.
> > > > >
> > > > > The Tree from extensions is the oldest one, without Ajax support.
> > > > > The Tree in core (as well as TreeTable) supports Ajax, but
> > > > > unfortunately suffers from layout problems and layout limitations,
> > > > > such as fixed line height, no way to wrap tree text or no way to add
> > > > > horizontal scrolling. Also the Tree is a bit difficult to customize.
> > > > >
> > > > > Fortunately, the base class that encapsulates the hard work (tree
> > > > > logic), AbstractTree, is pretty much presentation agnostic and it's
> > > > > not a big problem to build another component on it which would solve
> > > > > those layout problems.
> > > > >
> > > > > In fact, I've already such component done. It supports variable
> > > > > heights, content wrapping and horizontal scrolling. But the question
> > > > > is, where (and maybe even if) should we put it?
> > > > >
> > > > > The solution I want to propose may sound a bit radical. So I expected
> > > > > people want to yell on me and/or want kick my ball.
> > > > >
> > > > > Yet I'd like to
> > > > >
> > > > > a) remove the old (kinda unsupported) tree from extensions (is
> > > > > anyone even use it?)
> > > > > b) move the current Tree and TreeTable* from core to extensions
> > > > > (sight, i know we moved it into core just recently)
> > > > > c) move the new Tree into core.
> > > > >
> > > > > * I don't think it's a good idea to have a TreeTable in core anyway.
> > > > > We don't have DataTable in core and I'm pretty sure much more people
> > > > > are using DataTable then TreeTable.
> > > > >
> > > > > So... I know it's kinda late for things like this. But i was way too
> > > > > busy to do this sooner. Sorry.
> > > > >
> > > > > -Matej
> > > > >
> > > >
> > >
> >
> >
> > --
> > Join the wicket community at irc.freenode.net: ##wicket
> > Wicket 1.2.6 contains a very important fix. Download Wicket now!
> > http://wicketframework.org
> >
>
Re: Wicket Trees Situation
Posted by Matej Knopp <ma...@gmail.com>.
Yes, exactly. That's what I want.
-Matej
On 6/10/07, Martijn Dashorst <ma...@gmail.com> wrote:
> So for the tree and treetable nothing changes with respect to wicket
> 1.2? Both are in extensions, and a new tree replaces the old, pre ajax
> tree?
>
> Martijn
>
> On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> > I think it is much better.
> >
> > As for the TreeTable: The new TreeTable that I plan (without those
> > neat lines but also without layout problems) is not alive yet. And the
> > one that we already have should be moved back to extensions. I don't
> > think we need (nor should have) TreeTable in core.
> >
> > -Matej
> >
> > On 6/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > if it is really better then do it now before we put out rcs. also what
> > > happens to treetable? that should prob also move to extensions?
> > >
> > > -igor
> > >
> > >
> > > On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I hope this e-mail won't upset anyone too much.
> > > >
> > > > Let me summarize our tree components situation first.
> > > >
> > > > We have Tree and TreeTable components in core, and another Tree
> > > > component in extensions.
> > > >
> > > > The Tree from extensions is the oldest one, without Ajax support.
> > > > The Tree in core (as well as TreeTable) supports Ajax, but
> > > > unfortunately suffers from layout problems and layout limitations,
> > > > such as fixed line height, no way to wrap tree text or no way to add
> > > > horizontal scrolling. Also the Tree is a bit difficult to customize.
> > > >
> > > > Fortunately, the base class that encapsulates the hard work (tree
> > > > logic), AbstractTree, is pretty much presentation agnostic and it's
> > > > not a big problem to build another component on it which would solve
> > > > those layout problems.
> > > >
> > > > In fact, I've already such component done. It supports variable
> > > > heights, content wrapping and horizontal scrolling. But the question
> > > > is, where (and maybe even if) should we put it?
> > > >
> > > > The solution I want to propose may sound a bit radical. So I expected
> > > > people want to yell on me and/or want kick my ball.
> > > >
> > > > Yet I'd like to
> > > >
> > > > a) remove the old (kinda unsupported) tree from extensions (is
> > > > anyone even use it?)
> > > > b) move the current Tree and TreeTable* from core to extensions
> > > > (sight, i know we moved it into core just recently)
> > > > c) move the new Tree into core.
> > > >
> > > > * I don't think it's a good idea to have a TreeTable in core anyway.
> > > > We don't have DataTable in core and I'm pretty sure much more people
> > > > are using DataTable then TreeTable.
> > > >
> > > > So... I know it's kinda late for things like this. But i was way too
> > > > busy to do this sooner. Sorry.
> > > >
> > > > -Matej
> > > >
> > >
> >
>
>
> --
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>
Re: Wicket Trees Situation
Posted by Martijn Dashorst <ma...@gmail.com>.
So for the tree and treetable nothing changes with respect to wicket
1.2? Both are in extensions, and a new tree replaces the old, pre ajax
tree?
Martijn
On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> I think it is much better.
>
> As for the TreeTable: The new TreeTable that I plan (without those
> neat lines but also without layout problems) is not alive yet. And the
> one that we already have should be moved back to extensions. I don't
> think we need (nor should have) TreeTable in core.
>
> -Matej
>
> On 6/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > if it is really better then do it now before we put out rcs. also what
> > happens to treetable? that should prob also move to extensions?
> >
> > -igor
> >
> >
> > On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> > >
> > > Hi folks,
> > >
> > > I hope this e-mail won't upset anyone too much.
> > >
> > > Let me summarize our tree components situation first.
> > >
> > > We have Tree and TreeTable components in core, and another Tree
> > > component in extensions.
> > >
> > > The Tree from extensions is the oldest one, without Ajax support.
> > > The Tree in core (as well as TreeTable) supports Ajax, but
> > > unfortunately suffers from layout problems and layout limitations,
> > > such as fixed line height, no way to wrap tree text or no way to add
> > > horizontal scrolling. Also the Tree is a bit difficult to customize.
> > >
> > > Fortunately, the base class that encapsulates the hard work (tree
> > > logic), AbstractTree, is pretty much presentation agnostic and it's
> > > not a big problem to build another component on it which would solve
> > > those layout problems.
> > >
> > > In fact, I've already such component done. It supports variable
> > > heights, content wrapping and horizontal scrolling. But the question
> > > is, where (and maybe even if) should we put it?
> > >
> > > The solution I want to propose may sound a bit radical. So I expected
> > > people want to yell on me and/or want kick my ball.
> > >
> > > Yet I'd like to
> > >
> > > a) remove the old (kinda unsupported) tree from extensions (is
> > > anyone even use it?)
> > > b) move the current Tree and TreeTable* from core to extensions
> > > (sight, i know we moved it into core just recently)
> > > c) move the new Tree into core.
> > >
> > > * I don't think it's a good idea to have a TreeTable in core anyway.
> > > We don't have DataTable in core and I'm pretty sure much more people
> > > are using DataTable then TreeTable.
> > >
> > > So... I know it's kinda late for things like this. But i was way too
> > > busy to do this sooner. Sorry.
> > >
> > > -Matej
> > >
> >
>
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: Wicket Trees Situation
Posted by Matej Knopp <ma...@gmail.com>.
I think it is much better.
As for the TreeTable: The new TreeTable that I plan (without those
neat lines but also without layout problems) is not alive yet. And the
one that we already have should be moved back to extensions. I don't
think we need (nor should have) TreeTable in core.
-Matej
On 6/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> if it is really better then do it now before we put out rcs. also what
> happens to treetable? that should prob also move to extensions?
>
> -igor
>
>
> On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
> >
> > Hi folks,
> >
> > I hope this e-mail won't upset anyone too much.
> >
> > Let me summarize our tree components situation first.
> >
> > We have Tree and TreeTable components in core, and another Tree
> > component in extensions.
> >
> > The Tree from extensions is the oldest one, without Ajax support.
> > The Tree in core (as well as TreeTable) supports Ajax, but
> > unfortunately suffers from layout problems and layout limitations,
> > such as fixed line height, no way to wrap tree text or no way to add
> > horizontal scrolling. Also the Tree is a bit difficult to customize.
> >
> > Fortunately, the base class that encapsulates the hard work (tree
> > logic), AbstractTree, is pretty much presentation agnostic and it's
> > not a big problem to build another component on it which would solve
> > those layout problems.
> >
> > In fact, I've already such component done. It supports variable
> > heights, content wrapping and horizontal scrolling. But the question
> > is, where (and maybe even if) should we put it?
> >
> > The solution I want to propose may sound a bit radical. So I expected
> > people want to yell on me and/or want kick my ball.
> >
> > Yet I'd like to
> >
> > a) remove the old (kinda unsupported) tree from extensions (is
> > anyone even use it?)
> > b) move the current Tree and TreeTable* from core to extensions
> > (sight, i know we moved it into core just recently)
> > c) move the new Tree into core.
> >
> > * I don't think it's a good idea to have a TreeTable in core anyway.
> > We don't have DataTable in core and I'm pretty sure much more people
> > are using DataTable then TreeTable.
> >
> > So... I know it's kinda late for things like this. But i was way too
> > busy to do this sooner. Sorry.
> >
> > -Matej
> >
>
Re: Wicket Trees Situation
Posted by Igor Vaynberg <ig...@gmail.com>.
if it is really better then do it now before we put out rcs. also what
happens to treetable? that should prob also move to extensions?
-igor
On 6/10/07, Matej Knopp <ma...@gmail.com> wrote:
>
> Hi folks,
>
> I hope this e-mail won't upset anyone too much.
>
> Let me summarize our tree components situation first.
>
> We have Tree and TreeTable components in core, and another Tree
> component in extensions.
>
> The Tree from extensions is the oldest one, without Ajax support.
> The Tree in core (as well as TreeTable) supports Ajax, but
> unfortunately suffers from layout problems and layout limitations,
> such as fixed line height, no way to wrap tree text or no way to add
> horizontal scrolling. Also the Tree is a bit difficult to customize.
>
> Fortunately, the base class that encapsulates the hard work (tree
> logic), AbstractTree, is pretty much presentation agnostic and it's
> not a big problem to build another component on it which would solve
> those layout problems.
>
> In fact, I've already such component done. It supports variable
> heights, content wrapping and horizontal scrolling. But the question
> is, where (and maybe even if) should we put it?
>
> The solution I want to propose may sound a bit radical. So I expected
> people want to yell on me and/or want kick my ball.
>
> Yet I'd like to
>
> a) remove the old (kinda unsupported) tree from extensions (is
> anyone even use it?)
> b) move the current Tree and TreeTable* from core to extensions
> (sight, i know we moved it into core just recently)
> c) move the new Tree into core.
>
> * I don't think it's a good idea to have a TreeTable in core anyway.
> We don't have DataTable in core and I'm pretty sure much more people
> are using DataTable then TreeTable.
>
> So... I know it's kinda late for things like this. But i was way too
> busy to do this sooner. Sorry.
>
> -Matej
>
Re: Wicket Trees Situation
Posted by Matej Knopp <ma...@gmail.com>.
And. The new tree is not really compatible with old one, because there
is not much the old one does (in the terms of extendability). But in
case anyone needs the old (ajax) one, it will still be in extensions.
-Matej
On 6/10/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> * Matej Knopp:
> >
> > I hope this e-mail won't upset anyone too much.
> >
> > Let me summarize our tree components situation first.
> >
> > We have Tree and TreeTable components in core, and another Tree
> > component in extensions.
>
> [...]
>
> >
> > a) remove the old (kinda unsupported) tree from extensions (is
> > anyone even use it?)
> > b) move the current Tree and TreeTable* from core to extensions
> > (sight, i know we moved it into core just recently)
> > c) move the new Tree into core.
>
> If the new Tree is backwards compatible with the other, I would
> opt for c)
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Wicket Trees Situation
Posted by Matej Knopp <ma...@gmail.com>.
Err. Sorry for not-explaining it right. This is not a vote. What I
suggest are all those three options.
-Matej
On 6/10/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> * Matej Knopp:
> >
> > I hope this e-mail won't upset anyone too much.
> >
> > Let me summarize our tree components situation first.
> >
> > We have Tree and TreeTable components in core, and another Tree
> > component in extensions.
>
> [...]
>
> >
> > a) remove the old (kinda unsupported) tree from extensions (is
> > anyone even use it?)
> > b) move the current Tree and TreeTable* from core to extensions
> > (sight, i know we moved it into core just recently)
> > c) move the new Tree into core.
>
> If the new Tree is backwards compatible with the other, I would
> opt for c)
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Wicket Trees Situation
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Matej Knopp:
>
> I hope this e-mail won't upset anyone too much.
>
> Let me summarize our tree components situation first.
>
> We have Tree and TreeTable components in core, and another Tree
> component in extensions.
[...]
>
> a) remove the old (kinda unsupported) tree from extensions (is
> anyone even use it?)
> b) move the current Tree and TreeTable* from core to extensions
> (sight, i know we moved it into core just recently)
> c) move the new Tree into core.
If the new Tree is backwards compatible with the other, I would
opt for c)
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/