RichFaces 4.0: <tbody> elements in the DataTable html mockup

[abelevich]

Hi all,

    In this post I want to describe specific feature of  dataTable html mockup. The main reason I want to do this is using <tbody> elements to separate parent DataTable row and rows of SubTable  and provide something like "parent element/container" for the SubTable. The file DTD/xhtml1-strict.dtd says that <table> element could contain one or more <tbody> elements.  I decided use this possibility in the SubTable html mockup  i.e. if we have next DataTable

<dataTable>
     <column/>
     <column/>
     <column/>
     <subTable id="expandedSubTable">
          <column/>
          <column/>
     </subTable>
</dataTable>

rendered html will be:

//encode columns row
<tbody id="form1:j_idt6:0">
     <tr>
          SubTable columns html
     </tr>
</tbody>
//subTable
<tbody id="form1:j_idt6:0:expandedSubTable">
     [<tr>render header facet</tr>]
     //encode SubTable rows
      <tr>
          SubTable columns html
     </tr>
     ...
     <tr>
          SubTable columns html
     </tr>   
     [<tr>footer facet</tr>] 
</tbody>
<tbody id="form1:j_idt6:1">
     <tr>
          DataTable columns html
     </tr>
</tbody>
<tbody id="form1:j_idt6:1:expandedSubTable">
     [<tr>render header facet</tr>]
     <tr>
          SubTable columns html
     </tr>
     ...
     <tr>
          SubTable columns html
     </tr>
     [<tr>footer facet</tr>] 
</tbody>

benefits:

     This approach simplify expand/collapse feature implementation if we want toggle SubTable we simply find proper <tbody> element and hide/show it. Note that facets and SubTables rows will be hided too.

I think this is good solution. I don't see any pitfalls but maybe I missed something?

[alexsmirnov]

The main problem that I got with <tbody> tag from initial ajax4jsf is dynamic manipulations of that element in JavaScript ( AJAX updates ). Double check, is that markup could be properly inserted by AJAX in all supported browsers.

[abelevich]

alexsmirnov wrote:

The main problem that I got with <tbody> tag from initial ajax4jsf is dynamic manipulations of that element in JavaScript ( AJAX updates ). Double check, is that markup could be properly inserted by AJAX in all supported browsers.

I've implemented ajax expand/collapse for the subTables ...works in Chrome 4, FF3, Safari 4, IE8

[nbelaevski]

Cons:

1. In the 3.3.x implementation of filtering, TBODY element is updated in order to avoid keyboard focus loss after AJAX updates for THEAD elements. As we are going to support this, we'll need some way of issuing command to update all nested TBODY elements.
2. Scrollable TBODY elements (using "overflow: auto" or "overflow: scroll") are proposed as RFC into all supported browsers (FF already supports this). If the RFC is implemented, we'll need to modify table's code to support this as expected.
3. Additional TBODY elements can increase complexity of operating with the table via JS.

Pros:

1. sub-tables implemented via TBODY are easily updateable by AJAX

[abelevich]

nbelaevski wrote:

Cons:

1. In the 3.3.x implementation of filtering, TBODY element is updated in order to avoid keyboard focus loss after AJAX updates for THEAD elements. As we are going to support this, we'll need some way of issuing command to update all nested TBODY elements.

      We could add id's of DataTable TBODY and SubTable/SubTables TBODY to re-render during component processing ... don't see any problems here. Note that now there is a bug exists in the DataTable renderer each row is surrounded by TBODY element this will be fixed soon.

nbelaevski wrote:

     2. Scrollable TBODY elements (using "overflow: auto" or "overflow: scroll") are proposed as RFC into all supported browsers (FF already supports this). If the RFC is implemented, we'll need to modify table's code to support this as expected

       CSS 2.1 says that 'overflow' does not apply to table row group objects ...

nbelaevski wrote:

     3.Additional TBODY elements can increase complexity of operating with the table via JS.

       I think it will not adds much complexity

[nbelaevski]

abelevich wrote:

nbelaevski wrote:

Cons:

1. In the 3.3.x implementation of filtering, TBODY element is updated in order to avoid keyboard focus loss after AJAX updates for THEAD elements. As we are going to support this, we'll need some way of issuing command to update all nested TBODY elements.

      We could add id's of DataTable TBODY and SubTable/SubTables TBODY to re-render during component processing ... don't see any problems here. Note that now there is a bug exists in the DataTable renderer each row is surrounded by TBODY element this will be fixed soon.

That can decrease performance.

abelevich wrote:

nbelaevski wrote:

     2. Scrollable TBODY elements (using "overflow: auto" or "overflow: scroll") are proposed as RFC into all supported browsers (FF already supports this). If the RFC is implemented, we'll need to modify table's code to support this as expected

       CSS 2.1 says that 'overflow' does not apply to table row group objects ...

Right, but if this will be implemented by all major browsers, CSS specification will be updated too. 

[abelevich]

nbelaevski wrote:

abelevich wrote:

nbelaevski wrote:

Cons:

1. In the 3.3.x implementation of filtering, TBODY element is updated in order to avoid keyboard focus loss after AJAX updates for THEAD elements. As we are going to support this, we'll need some way of issuing command to update all nested TBODY elements.

      We could add id's of DataTable TBODY and SubTable/SubTables TBODY to re-render during component processing ... don't see any problems here. Note that now there is a bug exists in the DataTable renderer each row is surrounded by TBODY element this will be fixed soon.

That can decrease performance.

abelevich wrote:

nbelaevski wrote:

     2. Scrollable TBODY elements (using "overflow: auto" or "overflow: scroll") are proposed as RFC into all supported browsers (FF already supports this). If the RFC is implemented, we'll need to modify table's code to support this as expected

       CSS 2.1 says that 'overflow' does not apply to table row group objects ...

Right, but if this will be implemented by all major browsers, CSS specification will be updated too. 

     This is the question will be this implemented at all or not. Now only FF supports this feature another (IE, Chrome, Opera, Safari) doesn't. If you think that 'correct' (like FF do) processing of 'overlow' on TBODY is so important task we should change mockup. I don't see another good html solutions for the expand/collapse subTables within the bounds of one TABLE element. WDYT?

[jbalunas]

abelevich wrote:

alexsmirnov wrote:

The main problem that I got with <tbody> tag from initial ajax4jsf is dynamic manipulations of that element in JavaScript ( AJAX updates ). Double check, is that markup could be properly inserted by AJAX in all supported browsers.

I've implemented ajax expand/collapse for the subTables ...works in Chrome 4, FF3, Safari 4, IE8

FYI - IE 7 is also on the supported browser list.

[jbalunas]

Has there been any further discussion or desicions on this since the last post?

abelevich wrote:

nbelaevski wrote:

abelevich wrote:

nbelaevski wrote:

Cons:

1. In the 3.3.x implementation of filtering, TBODY element is updated in order to avoid keyboard focus loss after AJAX updates for THEAD elements. As we are going to support this, we'll need some way of issuing command to update all nested TBODY elements.

      We could add id's of DataTable TBODY and SubTable/SubTables TBODY to re-render during component processing ... don't see any problems here. Note that now there is a bug exists in the DataTable renderer each row is surrounded by TBODY element this will be fixed soon.

That can decrease performance

Besides markup size and processing in render does this approach have other performance impact?  I'm not discounting those effects, I just want to understand if there are other things to consider.

Also can someone outline clearly where tbody is used currently.  It seems it is used in many places - it would be good to understand them for this discussion.

Also we might want to get Lex's oppinion as well.

[abelevich]

[e-mail] wrote:

abelevich wrote:

alexsmirnov wrote:

The main problem that I got with <tbody> tag from initial ajax4jsf is dynamic manipulations of that element in JavaScript ( AJAX updates ). Double check, is that markup could be properly inserted by AJAX in all supported browsers.

I've implemented ajax expand/collapse for the subTables ...works in Chrome 4, FF3, Safari 4, IE8

FYI - IE 7 is also on the supported browser list.

     checked under IE7. works too.

[abelevich]

Has there been any further discussion or desicions on this since the last post?

       yes we had a discussion about this. We decided use mockup with tbody elements.

Besides markup size and processing in render does this approach have other performance impact?  I'm not discounting those effects, I just want to understand if there are other things to consider.

      I didn't find any.

Also can someone outline clearly where tbody is used currently.  It seems it is used in many places - it would be good to understand them for this discussion.

       tbody currently used to separate rows belongs to the DataTable from rows belongs to the SubTable as you could see in the  html markup above.

Also we might want to get Lex's oppinion as well.

      will be great

[admitriev]

I think that proposal to use several TBODY tags is technologically correct. More info you can see here: http://www.w3.org/TR/html401/struct/tables.html#edef-TBODY

BTW, in future we can use new futures of TBODY (when they will release in all general browsers)

[abelevich]

Hi,

    During dataTable renderer implementation I found some limitations using <tbody> based markup for the dataTable/subTable components.

• First,  what we should do with subTables nested into another subTables. (Current subTable component implementation doesn't allow this)  Do we need this feature at all?   If yes, how it should be looked in html?

• Second, I want clarify what we should switch off expand/collapse feature for the subTables rendered with attribute "layout=vertical" (RF-1870) should be rendered without  surrounded tbody's elements;

if we disagreed with both restrictions we need this discuss this additionally as we have no clear vision on possible solutions for now.