6 Replies Latest reply on Apr 27, 2009 11:59 AM by kubek2k

rich:treeTable component

nbelaevski Mar 26, 2009 3:03 PM

Copied from http://www.jboss.org/index.html?module=bb&op=viewtopic&t=152941:

"kubek2k" wrote:
Hi, i've promised on #jsf to release the component I've been working on lately. So here it is:
http://kubek2k.w.ds14.agh.edu.pl/wiki/doku.php?id=programming:java:richfaces:treetable

<a href="http://kubek2k.w.ds14.agh.edu.pl/wiki/lib/exe/fetch.php?cache=cache&media=programming:java:richfaces:treetable_screenshot.png"><img src="http://kubek2k.w.ds14.agh.edu.pl/wiki/lib/exe/fetch.php?cache=cache&media=programming:java:richfaces:treetable_screenshot.png" width="100%"></img></a>

It's features consist of most of the simple rich:tree features + datascrolling and header rendering. I needs a lot of work and testing, but it works for the simplest cases. I would really appreciate any feedback (good or bad).

Some of the problems I'm still struggling with are:
* first of all collapsing and expanding nodes: as the table is rather flat structure, it's not that simple to rerender parts of it as for the simple tree (where there are a lots of recursed divs), and so I've decided to rerender the whole table on each collapse/expand event. It can be probably solved by sending added/removed parts(ids) by ajax requests, and do all the DOM modifications from JS, but my expertise on Ajax4JSF is rather weak, and I don't feel good enough to implement it well (need help).
* I've used a fake renderer to render the treeNodeFacet (the tree parts in the table), as i wanted to reuse renderer of the rich:tree component (I had no idea how to do it better)
* some of the code had to be copied and pasted due to the visibility restrictions
* for the component I've used as much as I could from UITree component, and for the rendering I've inherited (or copied ;) ) code from AbstractTableRenderer
* the number of rows is counted as a number of top level nodes (so the real row count of rows in the table can vary). There was a suggestion to add a possibility to count all the visible rows, but it has to be rethinked again :).
* lack of the onCollapse and onExpand js events (TBD)
* lack of drag-and-drop support

Thanks for any help/patches or pieces advice

k2k
--
http://kubek2k.w.ds14.agh.edu.pl

1. Re: rich:treeTable component

kubek2k Apr 24, 2009 8:33 AM (in response to nbelaevski)

ok - here is the summary for the last meeting about the treetable component:

21.04:
* the partial processing of the tree (adding new rows while expanding nodes) can be done by introducing request scoped onbeforedomupdate/oncomplete filled with code that adds new empty rows, which are then filled with data (nbelaevski), but we should wait until jsf2 come out (alexsmirnov) - **postponed**
* the fake renderer for rendering the column with nodes is not a problem (nbelaevski)
* I have to fill in the contributors agreement on behalf of my company (but right now it seems it's not working well) [[http://www.jboss.org/contributor]]

22.04:
* remove nested tables from the markup as much as I can
* the treetable should go back to the bare rich:tree TreeNode classes for model for compability
* to overcome lazy loading problem one could override the method Entry#getValue()
* the problem with getting count of the children remain unsolved but probably we will do some adapting job and still allow to use the TreeTableNode based model
* We've worked out new model of building the tree:

<rich:treeTable>
<rich:treeNode>
<rich:column />
<rich:treeColumn />
<rich:column />
</rich:treeNode>
</rich:treeTable>

* the treeColumn is the column with tree controls, it should have the width param to set the fixed size
* remove wrapping DIV
* I have to prepare a patch for rich:tree to have some of the methods protected
* leave the descriptions in tld's while these are filled by doc team
* css's will be made in the end
* the drag and drop won't be supported for now[[Internal Link]]

If you're interested in some particular parts of the component, want to help or complain :), give a shout here.

full log of talk can be found on http://kubek2k.w.ds14.agh.edu.pl/wiki/lib/exe/fetch.php?media=programming:java:richfaces:treetable:richfaces_treetable.log.txt
Actions
2. Re: rich:treeTable component

luxspes Apr 24, 2009 9:01 AM (in response to nbelaevski)

It is great that you are creating a new treeTable, I am sure it will be very useful, but I have big concern:

Does it share the excessive bandwidth use problem that the current dataGrid and tree components have ( http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151926 )? Or does it make use of something like jQuery and/or more sensible use of CSS to save on the amount of HTML generated?
Actions
3. Re: rich:treeTable component

luxspes Apr 24, 2009 9:19 AM (in response to nbelaevski)

I think I good way to determine if this new treetable does not generate an excessive amount of HTML would be to comparate it with this jQuery treetable component or even with the treetable of ExtJS , I think that it would be acceptable for it to be around two times as heavy as those, but not more.

What do you think? Is it time to start setting quotas on the weight of new rich faces controls?
Actions
4. Re: rich:treeTable component

jbalunas Apr 27, 2009 5:46 AM (in response to nbelaevski)

What do you think? Is it time to start setting quotas on the weight of new rich faces controls?

The bandwidth requirements of RichFaces components are a big part of the 4.0 plan. We will be doing a full review of the components, javascript libraries, and other factors. Although I don't think we'll have a "quota" there will be a more conscious effort to manage this.

We will also be looking into a testsuite that can check and report on the bandwidth usage.

-Jay
Actions
5. Re: rich:treeTable component

luxspes Apr 27, 2009 6:38 AM (in response to nbelaevski)

"jbalunas@redhat.com" wrote:
What do you think? Is it time to start setting quotas on the weight of new rich faces controls?

The bandwidth requirements of RichFaces components are a big part of the 4.0 plan. We will be doing a full review of the components, javascript libraries, and other factors. Although I don't think we'll have a "quota" there will be a more conscious effort to manage this.

I think this should be a priority (over creating new controls) because so far I have been forced due to the excessive bandwidth use to look for alternatives for the tooltip, the table, the tree and the menu components. If this problems are not solved soon, I not be able to justify the use of Richfaces with my bosses :'( .

We will also be looking into a testsuite that can check and report on the bandwidth usage.

And I think comparisons of bandwidth with "pure HTML/CSS/JavaScript" would be very important part of this optimizations, so far, I have been unable to find a HTML/CSS/JavaScript that uses the same or more bandwidth than a RichFaces one :'(

-Jay
Actions
6. Re: rich:treeTable component

kubek2k Apr 27, 2009 11:59 AM (in response to nbelaevski)

"luxspes" wrote:
It is great that you are creating a new treeTable, I am sure it will be very useful, but I have big concern:

Does it share the excessive bandwidth use problem that the current dataGrid and tree components have ( http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151926 )? Or does it make use of something like jQuery and/or more sensible use of CSS to save on the amount of HTML generated?

the treeTable component is based on a table renderer, so it will work mostly the same (so I don't think you're happy). Moreover it suffers from the problem that browsers don't like changing the structure of the already rendered tabe, so it's actaully kinda hard to implement (a lot of DOM manipulations, rebuilding it from javascript and so on - see the talk for more details).
For these components - i've seen the one from extjs and actually it's not the based component, so i wouldn't be able to do it similarly (I would but i don't want to duplicate the code).
Actions

Go to original post