Hi, Once drupal 6 is out I am going to be continuing my development of merging theme(table) to the formapi. I have gotten the #pre_render into the formapi so that we can generate the table from a drupal_render(). This means that the rendering of tables is moved into the form creation which will simplify a lot of the admin pages in that they will not need a theme() to create the page. In e-Commerce I have a few use cases where I would like to be able to alter the output of tables to include additional rows and columns, as well as extending the information in cells. One requested item is to be able to add shipping messages to transactions. This is easy enough, but then getting this information out is quite hard in that besides the invoice display, there is no where without altering core ec code to add it. With this I can add an additional row and display the message on the transaction search page. Here is my proof of concept. http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/gordon/table_te... It is written for Drupal 5, which is how I worked out that I needed the #pre_render to be able to build a table. Gordon. Sean Robertson wrote:

Got any examples of specific use cases?

Mike Cantelon wrote:

...

Is there any interest in adding hook support to table rows and cells to allow on-the-fly modification of table data by modules? Something like "table_alter($headers, $rows)" and/or "row_alter" and "cell_alter". Seems to me this would be easy to do by adding support for an "id" key for tables, rows, and/or cells so if the id is set the hook is invoked in other modules.

Cheers, Mike

Hi, #pre_render or form_alter will allow you to change the table anyway you want. I am also wanting to create a contrib module which will allow you to do this on Drupal 6 so I can make sure of this functionality in e-Commerce v5 Gordon. Moshe Weitzman wrote:

Thats great stuff, Gordon. Lets definately get this in early during D7 so we can use it everywhere ... #pre_render is the mechanism for modules to add columns? seems reasonable to me.

On 11/7/07, Gordon Heydon <gordon@heydon.com.au> wrote:

...

Hi,

Once drupal 6 is out I am going to be continuing my development of merging theme(table) to the formapi. I have gotten the #pre_render into the formapi so that we can generate the table from a drupal_render().

This means that the rendering of tables is moved into the form creation which will simplify a lot of the admin pages in that they will not need a theme() to create the page.

In e-Commerce I have a few use cases where I would like to be able to alter the output of tables to include additional rows and columns, as well as extending the information in cells.

One requested item is to be able to add shipping messages to transactions. This is easy enough, but then getting this information out is quite hard in that besides the invoice display, there is no where without altering core ec code to add it. With this I can add an additional row and display the message on the transaction search page.

Here is my proof of concept. http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/gordon/table_te...

It is written for Drupal 5, which is how I worked out that I needed the #pre_render to be able to build a table.

Gordon.

Sean Robertson wrote:

...

Got any examples of specific use cases?

Mike Cantelon wrote:

...

Is there any interest in adding hook support to table rows and cells to allow on-the-fly modification of table data by modules? Something like "table_alter($headers, $rows)" and/or "row_alter" and "cell_alter". Seems to me this would be easy to do by adding support for an "id" key for tables, rows, and/or cells so if the id is set the hook is invoked in other modules.

Cheers, Mike

!DSPAM:1000,473273dc242372016019361!

Hi, Earl Miles wrote:

Gordon Heydon wrote:

...

Hi,

Once drupal 6 is out I am going to be continuing my development of merging theme(table) to the formapi. I have gotten the #pre_render into the formapi so that we can generate the table from a drupal_render().

I am really against merging theme('table') and formapi for two reasons:

Merging theme('table') is not really the right words for it. None of theme('table') will be put into the fapi, but more just the ability to create the structure of the table and then the default fapi themes will format it.

1) I've already written that theme('table') is harmful to themers, in general. I want to see less use of it, not more.

I agree, theme('table') is a real pain, and I want it gone. Something as simple as a 3rd party module adding an additional column or changing a cell is completely beyond it. And the fact that a lot of system forms that have a theme functions just to run the form into a table is a pain. If I need to theme these forms, I just want to do the bare minimum, not recreate the entire form.

2) I feel very strongly that we do *too* much display-oriented work in fapi and we need to do less. We need to separate that work, not combine it more. Yes, we need to do it in such a way that we retain the power that we have, but right now we are giving the module developer power at the expense of the themer. This is a trend I am actively attempting to reverse.

Agreed. You should be able to create/describe the structure of table in the form, and then a theme function can just theme it. It would even be quite conceivable that people may just want to change the theme for the elements that make up the table. Gordon.

Hi, Gerhard Killesreiter wrote:

Earl Miles schrieb:

...

Gordon Heydon wrote:

...

Hi,

Once drupal 6 is out I am going to be continuing my development of merging theme(table) to the formapi. I have gotten the #pre_render into the formapi so that we can generate the table from a drupal_render(). I am really against merging theme('table') and formapi for two reasons:

...

1) I've already written that theme('table') is harmful to themers, in general. I want to see less use of it, not more.

...

2) I feel very strongly that we do *too* much display-oriented work in fapi and we need to do less. We need to separate that work, not combine it more. Yes, we need to do it in such a way that we retain the power that we have, but right now we are giving the module developer power at the expense of the themer. This is a trend I am actively attempting to reverse.

I am fearing the performance implications...

Yes, that is on my mind as well. But I hope that it is no worse than the the current system, but we will not know that until it is done. Gordon.

Cheers, Gerhard

!DSPAM:1000,4732bf2e266621468016628!

Hi, No this is a replacement for theme('table') to give much better control. Gordon. David Metzler wrote:

I don't know that this is relevant, but I've been writing general form api helper functions that embed form fields in a table via a field-set (e.g. everything in a column is checkbox) and merge the returned form values back into an array based on a field naming convention.

Right now this is part of a php 5 dependent module, (xml_ui) and so not really ready for syndication.

But if you find it helpful, I'd certainly be willing to share code with you. (also won't be offended if you don't use it).

For me, form fields within a table is more interesting than hook_table, but hey, I'm just one guy.

On Nov 8, 2007, at 4:55 AM, Gordon Heydon wrote:

...

Hi,

Gerhard Killesreiter wrote:

...

Earl Miles schrieb:

...

Gordon Heydon wrote:

...

Hi,

Once drupal 6 is out I am going to be continuing my development of merging theme(table) to the formapi. I have gotten the #pre_render into the formapi so that we can generate the table from a drupal_render(). I am really against merging theme('table') and formapi for two reasons:

...

1) I've already written that theme('table') is harmful to themers, in general. I want to see less use of it, not more.

...

2) I feel very strongly that we do *too* much display-oriented work in fapi and we need to do less. We need to separate that work, not combine it more. Yes, we need to do it in such a way that we retain the power that we have, but right now we are giving the module developer power at the expense of the themer. This is a trend I am actively attempting to reverse.

I am fearing the performance implications...

Yes, that is on my mind as well. But I hope that it is no worse than the the current system, but we will not know that until it is done.

Gordon.

...

Cheers, Gerhard

!DSPAM:1000,4733d0c626261702512215!

On Friday 09 November 2007, Jeff Eaton wrote:

I agree that theme_table() is an ugly beast to override. However, I'm not sure what the alternative is. "using less of it" means either using less tables, or having several million tpl.php files lying around core whose only purpose is to wrap strings in <td> tags. All of these tpl.php's must be upgraded whenever one wants to change the classes or other 'wrapper' data for tables on a sitewide basis. Am I misunderstanding what you mean when you say we should move away from it?

I agree that we're adding flexibility "at the expense of themers." However, I think that's a necessary evil in many places. Any sufficiently complex structure *requires PHP code to render*, rather than simple print() statements. My feeling is that it's a fact of life, and the only way to change that is to make the functions in question essentially unthemable -- collapsing them to such "dumbed down" pre-rendered strings that we've just duplicated the old $node-

...

body problem again.

--Jeff

OK, I really have to ask... am I the only one who actually likes theme_table()? ;-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Nov 13, 2007 12:30 PM, Khalid Baheyeldin <kb@2bits.com> wrote:

...

OK, I really have to ask... am I the only one who actually likes theme_table()? ;-)

I don't like it, but I don't hate it either. I guess it is OK for me.

Perhaps use cases on why it is unwieldy?

theme_table is not so much the problem - it's just theming a table. The problem usually is extending the dataset prior to theming. The typical solution is "override the theme_table function and you can add columns there" - but thus ends the separation of form and function.