[tree2] Node Expansion & Dynamic Data

[Sean Schofield <se...@gmail.com>]

As promised I'd like to kick off a mini tree2 summit where we can
discuss some of the ideas that are being kicked around.  Yesterday I
closed out some of the easier tree2 related issues in JIRA.  There are
a few remaining which I'd like to address now.  Most of the
outstanding bugs can be addressed once we resolve a few key issues.

One possible change to tree2 that we might want to consider is making
TreeModel an interface and moving the code in the current TreeModel
class to a new DefaultTreeModel class.  The idea would be that users
could supply their own TreeModel using something like <x:tree2
model=#{MyModel} ...> If no model was specified, the DefaultTreeModel
could be used (basically what you have now.)

This might help users who want to specify their data dynamically. 
Instead of requiring that the user have all of the data loaded at once
in a node hierarchy, you could implement the getNode() methods, etc.
in any manner that you wanted.  Of course, this would only really
apply to server side toggle (sst).  Client side toggle (cst) might be
possible with Ajax but lets not go down that road just yet :-)

I don't have a current need for this type of feature so those of you
looking to have dynamic trees in this manner should comment on whether
or not this change would be helpful.  Also, my thinking is that we
still require the node data to implement the TreeNode interface.  Its
just that your custom model can wrap the data on the fly as needed
(instead of doing this for all of your data at once.)

There could be another possible impact on adding a TreeModel interace.
 We could add methods for determining the expand/collapse state of
nodes.  I haven't thought this through completely but the thinking was
that TreeModel (and DefaultTreeModel) would have isNodeExpanded() and
isNodeSelected() methods.

Mathias Werlitz has also suggested that UITreeData could extend
UIData.  The code behind the current UITreeData is heavily influenced
by UIData.  It deals with many of the same complex challenges (like
iterrating over the data when encoding and decoding.)  My thinking on
this is that we leave UITreeData as extending UIComponentBase but that
we fine tune it to deal with the use case of containing other
components that render their own children.

So those are some thoughts to get us started.  

sean

Re: [tree2] Node Expansion & Dynamic Data

[Sean Schofield <se...@gmail.com>]

I've had a few people email me asking about tree2 status so I'm
bumping this message to the top of the list for people to respond to. 
Please see the archives for the original part of this thread.

sean

On 7/26/05, Sean Schofield <se...@gmail.com> wrote:
> > Some of my larger tree2 forms are incredibly slow - even slower than the
> > JIRA.  As many other users, I approached the problem with a lazy load
> > mechanism.
> >
> > It turned out the bottleneck was bandwidth.  One page was a 1.7 MB download.
> >  I am now extending the renderer and using CSS instead of HTML attributes
> > for the many elements generated by tree2 .  Using a few sed scripts, I
> > estimate this'll cut bandwidth by over 80%.  Another idea I had was to just
> > make the renderer send an XML document (it is hierarchical data) and tell
> > the client to use XSLT.  This would cut bandwidth and push the processing
> > task to the client.
> 
> If you have a huge amount of data in a tree its going to take a long
> time to render that tree no matter what kind of mechanism you use to
> generate the HTML.  A 10,000 row table with nested tables is going to
> be slow no matter what!
> 
> For such large trees I think client-side toggle (CST) does not make
> sense.  Just accept the slightly slower response time of the SST
> version.  CST is the only reason why you would have such a large tree
> as you are describing (b/c all of the nodes are needed at once.)  Why
> else would you be pushing down such a big tree?
> 
> > This does not mean the lazy load issue is not important, I'm saying that
> > there are other parts to the puzzle.  As far as your ideas about being able
> > to specify the a model vendor via the tag attributes, I agree - this would
> > be great.  But I have always feared that a post like that would get me
> > smacked down by any few spec authors who might be listening - after all,
> > that literally puts "model" inside a tag called "view" .
> 
> All you are doing is allowing the user the ability to plug in their
> own model along with the data.  Swing already allows for this with its
> tree.  Its just MVC.  You are not really mixing M +  V, you are just
> specifying the M that the V should use.
> 
> > Dennis Byrne
> 
> sean
>

Re: [tree2] Node Expansion & Dynamic Data

[Sean Schofield <se...@gmail.com>]

> Some of my larger tree2 forms are incredibly slow - even slower than the
> JIRA.  As many other users, I approached the problem with a lazy load
> mechanism.   
>  
> It turned out the bottleneck was bandwidth.  One page was a 1.7 MB download.
>  I am now extending the renderer and using CSS instead of HTML attributes
> for the many elements generated by tree2 .  Using a few sed scripts, I
> estimate this'll cut bandwidth by over 80%.  Another idea I had was to just
> make the renderer send an XML document (it is hierarchical data) and tell
> the client to use XSLT.  This would cut bandwidth and push the processing
> task to the client.   

If you have a huge amount of data in a tree its going to take a long
time to render that tree no matter what kind of mechanism you use to
generate the HTML.  A 10,000 row table with nested tables is going to
be slow no matter what!

For such large trees I think client-side toggle (CST) does not make
sense.  Just accept the slightly slower response time of the SST
version.  CST is the only reason why you would have such a large tree
as you are describing (b/c all of the nodes are needed at once.)  Why
else would you be pushing down such a big tree?

> This does not mean the lazy load issue is not important, I'm saying that
> there are other parts to the puzzle.  As far as your ideas about being able
> to specify the a model vendor via the tag attributes, I agree - this would
> be great.  But I have always feared that a post like that would get me
> smacked down by any few spec authors who might be listening - after all,
> that literally puts "model" inside a tag called "view" .   

All you are doing is allowing the user the ability to plug in their
own model along with the data.  Swing already allows for this with its
tree.  Its just MVC.  You are not really mixing M +  V, you are just
specifying the M that the V should use.
  
> Dennis Byrne 

sean

Re: [tree2] Node Expansion & Dynamic Data

[De...@ak.blm.gov]

Some of my larger tree2 forms are incredibly slow - even slower than the 
JIRA.  As many other users, I approached the problem with a lazy load 
mechanism. 

It turned out the bottleneck was bandwidth.  One page was a 1.7 MB 
download.  I am now extending the renderer and using CSS instead of HTML 
attributes for the many elements generated by tree2 .  Using a few sed 
scripts, I estimate this'll cut bandwidth by over 80%.  Another idea I had 
was to just make the renderer send an XML document (it is hierarchical 
data) and tell the client to use XSLT.  This would cut bandwidth and push 
the processing task to the client. 

This does not mean the lazy load issue is not important, I'm saying that 
there are other parts to the puzzle.  As far as your ideas about being 
able to specify the a model vendor via the tag attributes, I agree - this 
would be great.  But I have always feared that a post like that would get 
me smacked down by any few spec authors who might be listening - after 
all, that literally puts "model" inside a tag called "view" . 

Dennis Byrne