Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.8.4

Request #4712 add possibility to add <thead>, <tfoot>, <tbody> tags
Submitted: 2005-06-29 21:25 UTC
From: wiesemann Assigned: dufuz
Status: Closed Package: HTML_Table
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  


 [2005-06-29 21:25 UTC] wiesemann
Description: ------------ Please add a possibilty to add <thead>, <tfoot> and <tbody> tags to the generated tables. This allows to do something like in example on http://validweb.nl/artikelen/javascript/better-zebra-tables/example1.html where you can see a hover effect on the table rows (the "zebra style" shown there has nothing to do with this request). With having a <tbody> around the real body rows only the body rows will have this hover effect. It does not make much sense to have this effect on header and footer rows. Please note that the (X)HTML standard requires the order <thead>, <tfoot>, <tbody> even if the footer elements normally should be written after the body elements. My suggestion: - add functions setTHead($startRow, $endRow = null), setTBody(...), setTFoot(...), where one can specify the rows numbers for these tags ($endRow optional, if null then set $endRow = $startRow) - output the table using <thead>, <tfoot> and <tbody> only if the three functions were called by a script, otherwise output the table as it is done now I can provide a patch if this request is accepted.

Comments

 [2005-08-14 15:38 UTC] wiesemann
As there was no response on my posting on php.pear.dev (http://news.php.net/php.pear.dev/39257), I try to ask here again: Is Christian Weiske's concept (described in http://news.php.net/php.pear.dev/39248) the way we should go? Is HTML_Table_Storage (http://news.php.net/php.pear.dev/39257) an acceptable name for the data class? Should this get HTML_Table2 (http://news.php.net/php.pear.dev/39249) or should it remain 1.x.y with the new code that works the way Christian described it? Do you still want me to make a patch?
 [2005-08-16 10:52 UTC] dufuz
IMHO v1 if you can make this patch in a BC kind of way, so that people can use either. But if this means that the old way will be thrown out then I must say that this would have to go into v2 package (and be PHP 5 while we are at it.) Anyway I like the concept, but as before, BC is important if it should stay v1, people that are already using the package must be able to upgrade with out altering any of their code if it stays v1 :P
 [2005-08-16 11:07 UTC] wiesemann
Okay, then I will make the patch - keeping full BC, so it can stay 1.x.y.
 [2005-08-18 12:27 UTC] wiesemann
The patch is ready: - patch for Table.php against current CVS version: http://www.markwiesemann.de/php/HTML_Table/HTML_Table.diff - patched Table.php as .phps: http://www.markwiesemann.de/php/HTML_Table/Table.phps - new Table/Storage.php as .phps: http://www.markwiesemann.de/php/HTML_Table/Storage.phps - both files as ZIP-file with directory Table: http://www.markwiesemann.de/php/HTML_Table/HTML_Table.zip Some notes about the patch: - both classes extend HTML_Common (because both use _getAttrString) - both constructors have a new third parameter $useTGroups, default is false to keep BC - in both constructors $tabOffset is casted to int (this allows to do $table = new HTML_Table(null, null, true);) - this version keeps full BC, all old function in Table.php pass their parameters to the moved functions in $this->_tbody; and if $useTGroups is false, only $this->_tbody get's rendered (without <tbody>, </tbody> around it, of course) - if $useTGroups is true, only the groups with at least one row will be rendered - if $useTGroups is false, <thead> and <tfoot> will be ignored even if they have contents, there is also no <tbody> tag around the table rows - this patch also includes request #4944, allowing to pass an array as $contents in setCellContents(); for this there is a new (private) _setSingleCellContents function in Storage.php Usage: - current behaviour is still available: $table = new HTML_Table(); $table->setCellContents(...); echo $table->toHtml(); - new alternative with same result: $table = new HTML_Table(); $body =& $table->getBody(); $body->setCellContents(...); echo $table->toHtml(); - using the new grouping: $table = new HTML_Table(null, null, true); $head =& $table->getHeader(); $foot =& $table->getFooter(); $body =& $table->getBody(); $head->setCellContents(...); $body->setCellContents(...); echo $table->toHtml(); // <tfoot> will not be rendered Comments and tests are welcome!
 [2005-08-31 03:30 UTC] dufuz
Sorry for not having had time to look at this, been meaning to, have you talked to Christian about what he thinks, since you two were much more "involved" in how the design would be then me or the other leads. Would be nice to see his comments here as a starting point, but I'll try to review this asap *putting on a post it todo note* ;)
 [2005-08-31 20:19 UTC] cweiske
Some notes: - first thanks for your work, Mark. - When I do a simple "$tbl->setCellContents(2, 1, 'bababa');" and echo the toHtml() output, I get nothing - although the original table class put something out. - Maybe (really only maybe) it'd be nice if head and foot are only initialized when doing a getHeader() or getFooter() - and automatically setting the $_useTGroups to true when doing this. - I don't know if the specs allow it to have only one col in the body but more in the footer or header (or vice versa). What I want to say: The rows should be filled up with empty cells to the *maximum of cols in body, head and foot*. if the head has 3 cols at maximum and the body max. 2, the body should be filled up with extra empty cells to get 3 as well.
 [2005-08-31 22:58 UTC] wiesemann
> - When I do a simple "$tbl->setCellContents(2, 1, > 'bababa');" and echo the toHtml() output, I get nothing - although > the original table class put something out. That's based on a bug in current CVS version, see #4656 which refers to a fix for #1734. When changing that back, I get the correct output. (There is also currently the wrong code line "$this_cols = $col;" in CVS.) I have updated the files on my server. > - Maybe (really only maybe) it'd be nice if head and foot are only > initialized when doing a getHeader() or getFooter() - and automatically > setting the $_useTGroups to true when doing this. Okay, this would also make the change to use the grouping for user easier - they don't need to add parameters to the constructor. But it would make this "optional": Leave the parameter in the constructor and initialize the header and footer parts ($useTGroups == true). In getHeader(), getFooter() and also getBody() I would add something like this (and make $attributes and $tabOffset from constructor class variables): if (is_null($this->_thead)) { $this->_thead =& new HTML_Table_Storage($this->_attributes, $this->_tabOffset, $this->_useTGroups); } return $this->_thead; With these two ways (constructor or getHeader/getFooter/getBody) we are more flexible and one can get a <tbody> around ones rows with using one of the get...() methods. > The rows should be filled up with empty cells to the *maximum of cols > in body, head and foot*. if the head has 3 cols at maximum and the body > max. 2, the body should be filled up with extra empty cells to get 3 as > well. Good idea. I have included this also in the files on my server.
 [2005-09-01 05:32 UTC] cweiske
I would always initialize the body, only thead and tfoot when needed - tbody is used in all cases.
 [2005-09-01 08:35 UTC] wiesemann
I have updated the files on my server: They include now also Christian's request to activate $_useTGroups via calling getHeader() or getFooter() as an alternative to the third constructor parameter.
 [2005-09-03 01:27 UTC] leonardo at republicadigital dot com dot br
I've been thinking about HTML_Table and I would like to share my ideas. what seems a MVC type of behaviour like QuickForm and yours renderers ? I'm working on class that is a abstraction of "Theme" to improve the use of QuickForm in my applications. something as $form->setTheme($themeName, $options); I hope to share and help HTML_Table... regards
 [2005-09-05 11:32 UTC] wiesemann
Leonardo, how is this related to _this_ request? If it is related, please write in more details. If it is not, please open a new feature request, contact the maintainers direclty or write to the pear-dev list.
 [2005-09-09 13:02 UTC] dufuz
I'm committing this now, Mark would you like to become a developer on HTML_Table to maintain your changes ?
 [2005-09-09 17:42 UTC] wiesemann
Hi Helgi, yes, I would like to maintain my additions to HTML_Table. Then I could also correct my name in package.php/.xml. ;-) I will also prepare a patch for peardoc so the new behaviour is described in the manual. This will take some days, I'm quite busy currently. (And sorry for adding the author tags in the wrong places, I must have mixed up the files when adding these.)
 [2005-09-24 09:43 UTC] wiesemann
Here is a patch for peardoc: http://www.markwiesemann.de/php/HTML_Table/peardoc.patch It includes: - html-table.xml (links to three new files) - html-table/intro.xml (new section explaining the usage) - html-table/html-table.xml ("see also" links to the new functions, explanation for the new third constructor param, correction for the second param ["unused" was wrong]) The files for the three new function can be found here: http://www.markwiesemann.de/php/HTML_Table/peardoc.zip Attention: - I'm not a native english speaker. Please re-read and correct it. - I haven't tested the files. (Lack of time and lack of a peardoc built system on my machine, currently.) Manual built and/or layout may be broken.
 [2005-09-24 16:46 UTC] dufuz
This is not the right place for this patch Mark, email pear-doc or get karma for it.