This patch integrates the specific signs '^' and '{' when using Drupal's theme layer. So if you use 'table=theme' you're now able to merge cells. Moreover the patch eliminates the '!'-signs in this context, because always the first table row cells are considered as <th>. Finally it enables you to use phptemplate_table() or YOURTHEME_table() in the template.php of your theme to make final adjustments.
All this is somehow half the way, because I think the theme layer should be generally used for output. If this would be the case, then you would be extremly flexible: let's say you have this:
[table class=myclass summary=The_summary_of_this_table. caption=My_header
| header A | header B | header C |
| contents cell 1 | contents cell 2 | contents cell 3 |
class=importantrow | data 4 | data 5 |class=red data 6 |
| data 7 | ^ merged | data 9 |
]
- A cell could begin and end with a '|' - and would give you 3 benefits: a) not to deal with Drupal's line break converter and b) to be able to add table row attributes at the beginning of a line and c) to have better usability since even the macro itself looks more like a table.
- I wouldn't specify attribute names - I would parse the first occurencies of foo=bar and treat them as attributes: on the table layer at the first row after '[table', on the row layer at each beginning of a line and on the cell layer after each '|'.
Does this make sense? What do ypou think?
Comments
Comment #1
tumblingmug commentedAnd the patch.
Comment #2
realityloop commentedMy main concern here is how it would render existing code saved in nodes if a user was to upgrade the module..
IE. will it be backward compatible.
Comment #3
tumblingmug commentedThe patch itself is backward compatible since it's rather a bug fix.
Syntax changes in general break existing code, good old issue, so your concern is right. Maybe is this the begin of a discussion for a D7-port? But I'm not sure, that the effort will be appreciated. The module is not much used by the community - I wonder how all the people deal with quick table creating? They all do this with WYSIWYG editors or the views module? I like the filter approach for quick and static tables very much. If all output of tables filter would go through the theming layer, you would have a maximum of theme safety while needing a minimum of macro code. And you benefit from Drupal table stuff like 'sticky headers' without having to do anything. And most important maybe: you inherit your special themes table design also by doing nothing. So my first vote would be to make the class 'theme' the predefined option. But even this could break existing table filter content; so for now the patch should be safe and doesn't break anything.
Comment #4
realityloop commentedFunny you say that as I am personally using wysiwyg nowdays, though I don't think that means we should drop the module.. it does meet specific use cases needs. are you interested in co-maintaining?
Comment #5
tumblingmug commentedNice of you, thanks. Let me think about it for some time. But in my opinion it would be kind at first if you would commit the patch, because - as I said - it fixes bugs. Try this before and after applying the patch:
To use "table=theme" is proposed by the module, so the patch fixes bugs definitely. It will not break existing tables.
Comment #6
realityloop commentedIncorporated in 6.x-1.3
Comment #7
tumblingmug commentedThx.