[development] Table hook idea

[Jeff Eaton]

On Nov 8, 2007, at 12:26 AM, Earl Miles wrote:

> 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.


Regarding the earlier statement, #pre_render and #post_render are not  
FormAPI constructs. Rather they are RenderAPI constructs implemented  
in our generic element-level drupal_render() function. They were added  
as provisions for CCK's rendering components. I do agree about  
presentation assumptions in FAPI; things like label positions, wrapper  
tags, and so on are very difficult to override without going deep into  
code and embedding more formatting 'tricks' right into FAPI's  
structure will make that even trickier.

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