Closed dankurka closed 9 years ago
Instead of as API like:
void setHeaderRowCount(int count);
How about something more like:
insertHeaderCell(int row, int column);
It seems to me like it might be preferable to treat the header and body separately
like this for a couple reason:
1. It would be nice for users of the API to be able to generate the table body
without having to account for how many header rows they have (e.g.
"insertHeaderCell(row + numHeaderRows, column)")
2. Calling something like setHeaderRowCount would require a lot more DOM
manipulation. Imagine you make a table and then call setHeaderRowCount(1). You take
the first header row out of the tbody and then append it to the thead. Then you have
to loop through that row and for each cell create a th element, move the current
cell's children to the new th, and remove the td element.
Reported by bmccann+legacy@google.com
on 2009-01-05 01:56:39
Here's a patch. Right now the HTMLTable assumes everything is acting on its tbody
element. Really that's not so good since we can have rows in thead or tfoot elements
as well, have multiple tbody elements, etc. The table should really be a collection
of row groups (thead, body, tfoot) each of which has a number of rows. I didn't go
quite so far as to create a new row group class, which is probably the best design
long term, but I did move us a lot closer. What I ended up doing was modifying a
number of the methods in the base class to take a row group element as an additional
parameter instead of simply assuming we were acting on the tbody.
I added some new methods to FlexTable to be able to modify the table header. I left
Grid alone in this first change to prove the patch wouldn't break third party code
which may have subclassed the base table.
Also, I was having trouble getting the tests to run, so while it compiles just fine
this is untested. And I've already spent more time than I was planning to on the
patch, so fabbott since you are listed as the owner of the issue and I assume you
were going to work on this anyway maybe you can take it from here? Feel free to ask
me about the patch or design issues though.
Reported by bmccann+legacy@google.com
on 2009-01-05 06:25:15
I view this sort of capability as critical. Anything that support assistive technologies
is far more important to my product than ui builders or even a client-side XPath.
Reported by thad.humphries
on 2010-07-20 17:44:48
The new CellTable coming in GWT 2.1 has the notion of column header and footer, that
will be rendered in thead and tfoot respectively:
http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/user/cellview/client/CellTable.html
http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/user/cellview/client/Header.html
Most (if not all) other needs are for "static tables", which you could build as "pure
HTML" tables in UiBinder.
Reported by t.broyer
on 2010-07-21 09:36:27
CellTable looks impressive, and I'll look into using it. All my data tables are dynamic,
and fixed headers when scrolling are appealing.
Though I haven't tired building a CellTable to see what Firebug says, from looking
at the com.google.gwt.user.cellview source it appears that cells created under a THEAD
are being created as TD vs TH. That means the Firefox Accessibility extension will
still flag the table as not suitable for assistive technology (see http://html.cita.illinois.edu/nav/dtable/).
Can this be changed? The idea would be that any cell in THEAD would be TH, while cells
in TBODY and TFOOT would be TD.
Reported by thad.humphries
on 2010-07-21 22:03:04
I'dd add that HTML5 even enforces the content model for THEAD to only contain TH cells
within its TR rows (see "content model" for the "tr" element):
http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-tr-element
Reported by t.broyer
on 2010-07-21 23:54:16
Any update on this?
Reported by Tapas.Adhikary
on 2011-12-27 15:09:26
CellTable in the upcoming GWT 2.5 have been refactored to use CellTableBuilder, HeaderBuilder
and FooterBuilder; the default implementation using <th> cells: http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/cellview/client/DefaultHeaderOrFooterBuilder.java
Reported by t.broyer
on 2011-12-28 19:08:30
FixedNotReleased
That looks great, but why not separate the validation code so that extending classes
do not have to reimplement the logic?
Reported by tuckerpmt
on 2011-12-28 20:58:23
Bulk edit: should be fixed in the GWT 2.5 release candidate.
Reported by skybrian@google.com
on 2012-06-27 03:38:11
Fixed
Originally reported on Google Code with ID 2956
Reported by
fabbott+personal@google.com
on 2008-10-07 14:57:30