You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Tapestry Stuff <ta...@gmail.com> on 2005/09/08 21:27:48 UTC
Presenting really large trees
Hi, wondering if anyone has come up with a nicer way to present LARGE sets
of hierarchical data. Trees are fine but the large set makes the tree
unwieldy. We have been using tacos tree for a long time but now the set has
grown so large as to cause us grief with page layout and looong db queries.
I think that persisting the tree is out of the question as the set is too
large.
Any ideas?
--
Nick
Re: Presenting really large trees
Posted by Jesse Kuhnert <jk...@gmail.com>.
I actually have the same problem with tacos trees. :)
The first step in a solution has been solved by making the tree Partially
renderable, ie ajax capable. This does however still require an initial load
of the tree, and depending on your tree's size this could become very
unwieldy.
The second stage in making the tree handle large data sets is going to be
something along the lines of either providing "live-grid" like behaviour,
where as you scroll down the tree it dynamically requests more tree nodes
(if it doesn't already have them), or the more simpler solution of providing
tree "paging" navigation links. Ie forward/backward/jump to /etc.. This
would be supported in ajax or non ajax modes.
The current tree I'm rendering can potentially display tens of thousands of
nodes (if they were all expanded), so I understand your problem very well :)
jesse
On 9/8/05, Tapestry Stuff <ta...@gmail.com> wrote:
>
> Hi, wondering if anyone has come up with a nicer way to present LARGE sets
> of hierarchical data. Trees are fine but the large set makes the tree
> unwieldy. We have been using tacos tree for a long time but now the set
> has
> grown so large as to cause us grief with page layout and looong db
> queries.
> I think that persisting the tree is out of the question as the set is too
> large.
>
> Any ideas?
>
> --
> Nick
>
>
Re: Presenting really large trees
Posted by Jonathan O'Connor <Jo...@xcom.de>.
Nick,
I went searching for this recently too. Apart from the left/right id trick,
you can also add the path as a field of the record. Thus:
ID PARENT_ID NAME PATH
1 null root root
2 1 A root.A
3 1 B root.B
4 2 X root.A.X
etc...
Now its easy to find all children of a given node:
Select * from NODES where path like 'root.A.%' // finds all children
of root/A
To check if a record has a given ancestor:
path.startsWith(ancestor.path)
Of course, if you want to move the folders around, then you will have to
update many records. Personally, I can't think of a clever piece of SQL to
do that, but then again, I'm no expert.
If you are worried about using large names, you could use stringified ids
as the path elements (e.g. node 4 would have a path: 1.2.4)
Lastly, I never bookmarked the link, but it should be easy to google.
Ciao,
Jonathan O'Connor
XCOM Dublin
Tapestry Stuff
<tapestry.stuff@g
mail.com> To
Tapestry users
08/09/2005 20:27 <ta...@jakarta.apache.org>
cc
Please respond to Subject
"Tapestry users" Presenting really large trees
<tapestry-user@ja
karta.apache.org>
Hi, wondering if anyone has come up with a nicer way to present LARGE sets
of hierarchical data. Trees are fine but the large set makes the tree
unwieldy. We have been using tacos tree for a long time but now the set has
grown so large as to cause us grief with page layout and looong db queries.
I think that persisting the tree is out of the question as the set is too
large.
Any ideas?
--
Nick
*** XCOM AG Legal Disclaimer ***
Diese E-Mail einschliesslich ihrer Anhaenge ist vertraulich und ist allein
für den Gebrauch durch den vorgesehenen Empfaenger bestimmt. Dritten ist
das Lesen, Verteilen oder Weiterleiten dieser E-Mail untersagt. Wir bitten,
eine fehlgeleitete E-Mail unverzueglich vollstaendig zu loeschen und uns
eine Nachricht zukommen zu lassen.
This email may contain material that is confidential and for the sole use
of the intended recipient. Any review, distribution by others or forwarding
without express permission is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
Re: Presenting really large trees
Posted by Jesse Kuhnert <jk...@gmail.com>.
That all depends on a number of factors I think. If said tree didn't have
any logic to handle these partial "ajax" requests then I would have to agree
about the performance problem..
I do know however that the latest version of the tacos tree ~does~ take into
account the fact that it is involved in a partial request, and so doesn't
cause any unneeded DB hits.
The content provider implementation that ~you~ provide does have to take the
partial request into account as well, otherwise all ajax requests would
result in you re-querying the entire result set that originally produced the
tree...
The content provider that I personally use along with the tacos tree uses
knowledge of the partial request, as well as parameters set on the page when
the nodes are selected to ONLY query the DB for the rows required to render
the request. Of course most of this was made a lot easier via the use of
hibernate, but normal JDBC operations should be able to do it just as
easily.
Where do you see the performance hit? If you are speaking of the LiveGrid
behaviour, I'd have to agree with you. At least in the current incarnation
that rico provides it in, which I don't personally agree with.
The paging mechanism makes more sense to me, and again I'd have to ask where
you see the performance breakdown? The "set" should be faster by many orders
of magnitude when adding additional parameters to your sql query, like a
range limiter of some sort. Unless the DB in question isn't properly
indexed, or the SQL being used to represent the tree is inherently flawed I
don't see the issue.
I am genuinely interested in what problems you forsee. If you could be more
specific it would help me rationalize a response.
jesse
On 9/8/05, Konstantin Ignatyev <kg...@yahoo.com> wrote:
>
> Would the 'nested set' work well or not does not
> depend on size, but on 'stability' of the tree.
>
> For 'stable' tree (updated nightly) nested set model
> does excellent job no matter what the size is. And of
> course I mean working hierarchical queries, not simple
> 'lazy' navigation.
>
>
> --- Karthik Abram <ka...@neovera.com> wrote:
>
> >
> >
> > This would work for small trees, not "really large
> > trees" as requested in
> > the email. For insertions and moves, you are good as
> > long as you can avoid
> > the "step" problem, however, when you do hit it, you
> > have to adjust half the
> > nodes. It gives particularly poor performance when
> > you have concurrent
> > operations.
> >
> > -----Original Message-----
> > From: Konstantin Ignatyev
> > [mailto:kgignatyev@yahoo.com]
> > Sent: Thursday, September 08, 2005 4:04 PM
> > To: Tapestry users
> > Subject: RE: Presenting really large trees
> >
> >
> > Not really. Left and Right values can be incremented
> > in 'steps' and depending on the step size we could
> > insert many nodes without the need to recalculate
> > entire tree.
> >
> > Deletion is always cheap - no recalculation
> > required.
> >
> >
> > --- Karthik Abram <ka...@neovera.com> wrote:
> >
> > >
> > > Thats a terrible model for a dynamic tree
> > though...
> > >
> > > -----Original Message-----
> > > From: Konstantin Ignatyev
> > > [mailto:kgignatyev@yahoo.com]
> > > Sent: Thursday, September 08, 2005 3:37 PM
> > > To: Tapestry users; tapestry.stuff@gmail.com
> > > Subject: Re: Presenting really large trees
> > >
> > >
> > > Not necessarily about UI, but 'nested set' tree
> > > representation works extremely well and simplifies
> > a
> > > lot of typical hierarchical queries
> > > http://www.dbmsmag.com/9603d06.html
> > >
> > > I recomment Joe's book 'SQL for Smarties'
> > >
> > > --- Tapestry Stuff <ta...@gmail.com>
> > wrote:
> > >
> > > > Hi, wondering if anyone has come up with a nicer
> > > way
> > > > to present LARGE sets
> > > > of hierarchical data. Trees are fine but the
> > large
> > > > set makes the tree
> > > > unwieldy. We have been using tacos tree for a
> > long
> > > > time but now the set has
> > > > grown so large as to cause us grief with page
> > > layout
> > > > and looong db queries.
> > > > I think that persisting the tree is out of the
> > > > question as the set is too
> > > > large.
> > > >
> > > > Any ideas?
> > > >
> > > > --
> > > > Nick
> > > >
> > >
> > >
> > > Konstantin Ignatyev
> > >
> > >
> > >
> > >
> > > PS: If this is a typical day on planet earth,
> > humans
> > > will add fifteen
> > > million tons of carbon to the atmosphere, destroy
> > > 115 square miles of
> > > tropical rainforest, create seventy-two miles of
> > > desert, eliminate between
> > > forty to one hundred species, erode seventy-one
> > > million tons of topsoil, add
> > > 2,700 tons of CFCs to the stratosphere, and
> > increase
> > > their population by
> > > 263,000
> > >
> > > Bowers, C.A. The Culture of Denial: Why the
> > > Environmental Movement Needs a
> > > Strategy for Reforming Universities and Public
> > > Schools. New York: State
> > > University of New York Press, 1997: (4) (5)
> > (p.206)
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
RE: Presenting really large trees
Posted by Karthik Abram <ka...@neovera.com>.
This is silly. In my original email, I stated "Thats a terrible model for a
dynamic tree though..."
EOT
-----Original Message-----
From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
Sent: Thursday, September 08, 2005 4:37 PM
To: Tapestry users
Subject: RE: Presenting really large trees
Would the 'nested set' work well or not does not
depend on size, but on 'stability' of the tree.
For 'stable' tree (updated nightly) nested set model
does excellent job no matter what the size is. And of
course I mean working hierarchical queries, not simple
'lazy' navigation.
--- Karthik Abram <ka...@neovera.com> wrote:
>
>
> This would work for small trees, not "really large
> trees" as requested in
> the email. For insertions and moves, you are good as
> long as you can avoid
> the "step" problem, however, when you do hit it, you
> have to adjust half the
> nodes. It gives particularly poor performance when
> you have concurrent
> operations.
>
> -----Original Message-----
> From: Konstantin Ignatyev
> [mailto:kgignatyev@yahoo.com]
> Sent: Thursday, September 08, 2005 4:04 PM
> To: Tapestry users
> Subject: RE: Presenting really large trees
>
>
> Not really. Left and Right values can be incremented
> in 'steps' and depending on the step size we could
> insert many nodes without the need to recalculate
> entire tree.
>
> Deletion is always cheap - no recalculation
> required.
>
>
> --- Karthik Abram <ka...@neovera.com> wrote:
>
> >
> > Thats a terrible model for a dynamic tree
> though...
> >
> > -----Original Message-----
> > From: Konstantin Ignatyev
> > [mailto:kgignatyev@yahoo.com]
> > Sent: Thursday, September 08, 2005 3:37 PM
> > To: Tapestry users; tapestry.stuff@gmail.com
> > Subject: Re: Presenting really large trees
> >
> >
> > Not necessarily about UI, but 'nested set' tree
> > representation works extremely well and simplifies
> a
> > lot of typical hierarchical queries
> > http://www.dbmsmag.com/9603d06.html
> >
> > I recomment Joe's book 'SQL for Smarties'
> >
> > --- Tapestry Stuff <ta...@gmail.com>
> wrote:
> >
> > > Hi, wondering if anyone has come up with a nicer
> > way
> > > to present LARGE sets
> > > of hierarchical data. Trees are fine but the
> large
> > > set makes the tree
> > > unwieldy. We have been using tacos tree for a
> long
> > > time but now the set has
> > > grown so large as to cause us grief with page
> > layout
> > > and looong db queries.
> > > I think that persisting the tree is out of the
> > > question as the set is too
> > > large.
> > >
> > > Any ideas?
> > >
> > > --
> > > Nick
> > >
> >
> >
> > Konstantin Ignatyev
> >
> >
> >
> >
> > PS: If this is a typical day on planet earth,
> humans
> > will add fifteen
> > million tons of carbon to the atmosphere, destroy
> > 115 square miles of
> > tropical rainforest, create seventy-two miles of
> > desert, eliminate between
> > forty to one hundred species, erode seventy-one
> > million tons of topsoil, add
> > 2,700 tons of CFCs to the stratosphere, and
> increase
> > their population by
> > 263,000
> >
> > Bowers, C.A. The Culture of Denial: Why the
> > Environmental Movement Needs a
> > Strategy for Reforming Universities and Public
> > Schools. New York: State
> > University of New York Press, 1997: (4) (5)
> (p.206)
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Presenting really large trees
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
Would the 'nested set' work well or not does not
depend on size, but on 'stability' of the tree.
For 'stable' tree (updated nightly) nested set model
does excellent job no matter what the size is. And of
course I mean working hierarchical queries, not simple
'lazy' navigation.
--- Karthik Abram <ka...@neovera.com> wrote:
>
>
> This would work for small trees, not "really large
> trees" as requested in
> the email. For insertions and moves, you are good as
> long as you can avoid
> the "step" problem, however, when you do hit it, you
> have to adjust half the
> nodes. It gives particularly poor performance when
> you have concurrent
> operations.
>
> -----Original Message-----
> From: Konstantin Ignatyev
> [mailto:kgignatyev@yahoo.com]
> Sent: Thursday, September 08, 2005 4:04 PM
> To: Tapestry users
> Subject: RE: Presenting really large trees
>
>
> Not really. Left and Right values can be incremented
> in 'steps' and depending on the step size we could
> insert many nodes without the need to recalculate
> entire tree.
>
> Deletion is always cheap - no recalculation
> required.
>
>
> --- Karthik Abram <ka...@neovera.com> wrote:
>
> >
> > Thats a terrible model for a dynamic tree
> though...
> >
> > -----Original Message-----
> > From: Konstantin Ignatyev
> > [mailto:kgignatyev@yahoo.com]
> > Sent: Thursday, September 08, 2005 3:37 PM
> > To: Tapestry users; tapestry.stuff@gmail.com
> > Subject: Re: Presenting really large trees
> >
> >
> > Not necessarily about UI, but 'nested set' tree
> > representation works extremely well and simplifies
> a
> > lot of typical hierarchical queries
> > http://www.dbmsmag.com/9603d06.html
> >
> > I recomment Joe's book 'SQL for Smarties'
> >
> > --- Tapestry Stuff <ta...@gmail.com>
> wrote:
> >
> > > Hi, wondering if anyone has come up with a nicer
> > way
> > > to present LARGE sets
> > > of hierarchical data. Trees are fine but the
> large
> > > set makes the tree
> > > unwieldy. We have been using tacos tree for a
> long
> > > time but now the set has
> > > grown so large as to cause us grief with page
> > layout
> > > and looong db queries.
> > > I think that persisting the tree is out of the
> > > question as the set is too
> > > large.
> > >
> > > Any ideas?
> > >
> > > --
> > > Nick
> > >
> >
> >
> > Konstantin Ignatyev
> >
> >
> >
> >
> > PS: If this is a typical day on planet earth,
> humans
> > will add fifteen
> > million tons of carbon to the atmosphere, destroy
> > 115 square miles of
> > tropical rainforest, create seventy-two miles of
> > desert, eliminate between
> > forty to one hundred species, erode seventy-one
> > million tons of topsoil, add
> > 2,700 tons of CFCs to the stratosphere, and
> increase
> > their population by
> > 263,000
> >
> > Bowers, C.A. The Culture of Denial: Why the
> > Environmental Movement Needs a
> > Strategy for Reforming Universities and Public
> > Schools. New York: State
> > University of New York Press, 1997: (4) (5)
> (p.206)
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Presenting really large trees
Posted by Karthik Abram <ka...@neovera.com>.
This would work for small trees, not "really large trees" as requested in
the email. For insertions and moves, you are good as long as you can avoid
the "step" problem, however, when you do hit it, you have to adjust half the
nodes. It gives particularly poor performance when you have concurrent
operations.
-----Original Message-----
From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
Sent: Thursday, September 08, 2005 4:04 PM
To: Tapestry users
Subject: RE: Presenting really large trees
Not really. Left and Right values can be incremented
in 'steps' and depending on the step size we could
insert many nodes without the need to recalculate
entire tree.
Deletion is always cheap - no recalculation required.
--- Karthik Abram <ka...@neovera.com> wrote:
>
> Thats a terrible model for a dynamic tree though...
>
> -----Original Message-----
> From: Konstantin Ignatyev
> [mailto:kgignatyev@yahoo.com]
> Sent: Thursday, September 08, 2005 3:37 PM
> To: Tapestry users; tapestry.stuff@gmail.com
> Subject: Re: Presenting really large trees
>
>
> Not necessarily about UI, but 'nested set' tree
> representation works extremely well and simplifies a
> lot of typical hierarchical queries
> http://www.dbmsmag.com/9603d06.html
>
> I recomment Joe's book 'SQL for Smarties'
>
> --- Tapestry Stuff <ta...@gmail.com> wrote:
>
> > Hi, wondering if anyone has come up with a nicer
> way
> > to present LARGE sets
> > of hierarchical data. Trees are fine but the large
> > set makes the tree
> > unwieldy. We have been using tacos tree for a long
> > time but now the set has
> > grown so large as to cause us grief with page
> layout
> > and looong db queries.
> > I think that persisting the tree is out of the
> > question as the set is too
> > large.
> >
> > Any ideas?
> >
> > --
> > Nick
> >
>
>
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans
> will add fifteen
> million tons of carbon to the atmosphere, destroy
> 115 square miles of
> tropical rainforest, create seventy-two miles of
> desert, eliminate between
> forty to one hundred species, erode seventy-one
> million tons of topsoil, add
> 2,700 tons of CFCs to the stratosphere, and increase
> their population by
> 263,000
>
> Bowers, C.A. The Culture of Denial: Why the
> Environmental Movement Needs a
> Strategy for Reforming Universities and Public
> Schools. New York: State
> University of New York Press, 1997: (4) (5) (p.206)
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Presenting really large trees
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
Not really. Left and Right values can be incremented
in 'steps' and depending on the step size we could
insert many nodes without the need to recalculate
entire tree.
Deletion is always cheap - no recalculation required.
--- Karthik Abram <ka...@neovera.com> wrote:
>
> Thats a terrible model for a dynamic tree though...
>
> -----Original Message-----
> From: Konstantin Ignatyev
> [mailto:kgignatyev@yahoo.com]
> Sent: Thursday, September 08, 2005 3:37 PM
> To: Tapestry users; tapestry.stuff@gmail.com
> Subject: Re: Presenting really large trees
>
>
> Not necessarily about UI, but 'nested set' tree
> representation works extremely well and simplifies a
> lot of typical hierarchical queries
> http://www.dbmsmag.com/9603d06.html
>
> I recomment Joe's book 'SQL for Smarties'
>
> --- Tapestry Stuff <ta...@gmail.com> wrote:
>
> > Hi, wondering if anyone has come up with a nicer
> way
> > to present LARGE sets
> > of hierarchical data. Trees are fine but the large
> > set makes the tree
> > unwieldy. We have been using tacos tree for a long
> > time but now the set has
> > grown so large as to cause us grief with page
> layout
> > and looong db queries.
> > I think that persisting the tree is out of the
> > question as the set is too
> > large.
> >
> > Any ideas?
> >
> > --
> > Nick
> >
>
>
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans
> will add fifteen
> million tons of carbon to the atmosphere, destroy
> 115 square miles of
> tropical rainforest, create seventy-two miles of
> desert, eliminate between
> forty to one hundred species, erode seventy-one
> million tons of topsoil, add
> 2,700 tons of CFCs to the stratosphere, and increase
> their population by
> 263,000
>
> Bowers, C.A. The Culture of Denial: Why the
> Environmental Movement Needs a
> Strategy for Reforming Universities and Public
> Schools. New York: State
> University of New York Press, 1997: (4) (5) (p.206)
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Presenting really large trees
Posted by Karthik Abram <ka...@neovera.com>.
Thats a terrible model for a dynamic tree though...
-----Original Message-----
From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
Sent: Thursday, September 08, 2005 3:37 PM
To: Tapestry users; tapestry.stuff@gmail.com
Subject: Re: Presenting really large trees
Not necessarily about UI, but 'nested set' tree
representation works extremely well and simplifies a
lot of typical hierarchical queries
http://www.dbmsmag.com/9603d06.html
I recomment Joe's book 'SQL for Smarties'
--- Tapestry Stuff <ta...@gmail.com> wrote:
> Hi, wondering if anyone has come up with a nicer way
> to present LARGE sets
> of hierarchical data. Trees are fine but the large
> set makes the tree
> unwieldy. We have been using tacos tree for a long
> time but now the set has
> grown so large as to cause us grief with page layout
> and looong db queries.
> I think that persisting the tree is out of the
> question as the set is too
> large.
>
> Any ideas?
>
> --
> Nick
>
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil, add
2,700 tons of CFCs to the stratosphere, and increase their population by
263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Presenting really large trees
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
Not necessarily about UI, but 'nested set' tree
representation works extremely well and simplifies a
lot of typical hierarchical queries
http://www.dbmsmag.com/9603d06.html
I recomment Joe's book 'SQL for Smarties'
--- Tapestry Stuff <ta...@gmail.com> wrote:
> Hi, wondering if anyone has come up with a nicer way
> to present LARGE sets
> of hierarchical data. Trees are fine but the large
> set makes the tree
> unwieldy. We have been using tacos tree for a long
> time but now the set has
> grown so large as to cause us grief with page layout
> and looong db queries.
> I think that persisting the tree is out of the
> question as the set is too
> large.
>
> Any ideas?
>
> --
> Nick
>
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org