Hi, I would like to ask everyone not to use literal <table> <tr> and <td> tags ongoing. We have a theme('table'). Trivial example: zebra. Instead of striping everything separately we can do it centrally. Thanks, Karoly Negyesi
Karoly Negyesi wrote:
Hi,
I would like to ask everyone not to use literal <table> <tr> and <td> tags ongoing. We have a theme('table').
Trivial example: zebra. Instead of striping everything separately we can do it centrally.
theme('table') is a really interesting conundrum. On pages that utilize tables, they are great for the programmer, and actually really hard on a designer. As we're moving toward templatizing the theme functions of Drupal, there turns out to be nothing to put into a .tpl.php for something that is, ultimately, just a table. On the other hand, not using theme('table') has the problem of leading to inconsistency. Right now you can do quite a bit by theming all of your tables...but no one ever (to my knowledge) actually overrides theme('table'), and most of that theming is done via CSS. I think what this really means is that theme('table') needs to be expanded in such a way that we can do named tables that will allow us to invoke individual templates in the manner of node.tpl.php. Something like table-forum_overview.tpl.php maybe. I've done a lot of back-and-forth with myself on this one, because there are arguments on either side of the fence that are really compelling. I'm curious to hear other people's thoughts on this one.
I think what this really means is that theme('table') needs to be expanded in such a way that we can do named tables that will allow us to invoke individual templates in the manner of node.tpl.php. Something like table-forum_overview.tpl.php maybe.
this sounds nice and consistent to me ... or we expand drupal_render usage and expect folks to override #theme if they want to take over themeing for a certain table. that seems like a more long term project, with more a bit more uncertainty.
On 21 Apr 2007, at 8:41 PM, Moshe Weitzman wrote:
this sounds nice and consistent to me ... or we expand drupal_render usage and expect folks to override #theme if they want to take over themeing for a certain table. that seems like a more long term project, with more a bit more uncertainty.
doesn't that work today though ? just needing a documentation change. ie: it always uses #theme if found, instead of the theme_#type.
Hi, adrian rossouw wrote:
On 21 Apr 2007, at 8:41 PM, Moshe Weitzman wrote:
this sounds nice and consistent to me ... or we expand drupal_render usage and expect folks to override #theme if they want to take over themeing for a certain table. that seems like a more long term project, with more a bit more uncertainty.
doesn't that work today though ? just needing a documentation change.
ie: it always uses #theme if found, instead of the theme_#type.
Yes does work, but not very well. You can change the look of your table, but that is about it. What I would love to see if being able to add new columns to a table, and then populate it will more information. An example would be the comment list, where you could add an additional column or row with hook_form_alter() and then it will get themed the way that you want it. Gordon.
!DSPAM:1000,462aafca298781821219920!
Gordon Heydon wrote:
Hi,
adrian rossouw wrote:
On 21 Apr 2007, at 8:41 PM, Moshe Weitzman wrote:
this sounds nice and consistent to me ... or we expand drupal_render usage and expect folks to override #theme if they want to take over themeing for a certain table. that seems like a more long term project, with more a bit more uncertainty.
doesn't that work today though ? just needing a documentation change.
i think it does. so whats needed is some general agreement that we should output tables not directly through theme('table') but rather with a construct like: $page['forum_overview'] = array( '#type' => 'table', '#header' => $header, '#rows' => $rows ) $output = drupal_render($page); the big advantage is that modules can alter a table as suggested by Gordon and that themers can override a single table with #theme. the disadvantage is a small performance dip. we'll do some benchmarking to understand the amount. note that i'm only talking about output of tables through drupal_render(), not whole page.
On 22.04.2007, at 14:48, Moshe Weitzman wrote:
i think it does. so whats needed is some general agreement that we should output tables not directly through theme('table') but rather with a construct like:
http://drupal.org/node/80855 might be related with this issue. Konstantin Käfer – http://kkaefer.com/
Fabio Varesano wrote:
note that i'm only talking about output of tables through drupal_render(), not whole page.
And why not extending this approach to all kind of pages? not just table pages.
Fabio
we'll get there one day. one step at a time. whole pages are hard.
Hi, Moshe Weitzman wrote:
Gordon Heydon wrote:
Hi,
adrian rossouw wrote:
On 21 Apr 2007, at 8:41 PM, Moshe Weitzman wrote:
this sounds nice and consistent to me ... or we expand drupal_render usage and expect folks to override #theme if they want to take over themeing for a certain table. that seems like a more long term project, with more a bit more uncertainty.
doesn't that work today though ? just needing a documentation change.
i think it does. so whats needed is some general agreement that we should output tables not directly through theme('table') but rather with a construct like:
$page['forum_overview'] = array( '#type' => 'table', '#header' => $header, '#rows' => $rows ) $output = drupal_render($page);
the big advantage is that modules can alter a table as suggested by Gordon and that themers can override a single table with #theme. the disadvantage is a small performance dip. we'll do some benchmarking to understand the amount.
note that i'm only talking about output of tables through drupal_render(), not whole page.
Yes I have actually started on this. Also I have done it so that it allows the naming of columns, so that hook_form_alter() can alter the contents of cells, and also so that you don't have to have all columns on all rows. Other advantages is that you can weight columns to put them where ever you want. This is something that I really need in E-Commerce for the transaction search table. Gordon.
!DSPAM:1000,462b593f101281670870668!
participants (7)
-
adrian rossouw -
Earl Miles -
Fabio Varesano -
Gordon Heydon -
Karoly Negyesi -
Konstantin Käfer -
Moshe Weitzman