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

    rich:treeTable component

    Nick Belaevski Master

      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
          Jakub Janczak Newbie

          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

          • 2. Re: rich:treeTable component
            Francisco Jose Peredo Noguez Master

            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?

            • 3. Re: rich:treeTable component
              Francisco Jose Peredo Noguez Master

              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?

              • 4. Re: rich:treeTable component
                Jay Balunas Master

                 

                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



                • 5. Re: rich:treeTable component
                  Francisco Jose Peredo Noguez Master

                   

                  "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



                  • 6. Re: rich:treeTable component
                    Jakub Janczak Newbie

                     

                    "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).