Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
theme system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
14 Oct 2012 at 14:10 UTC
Updated:
29 Jul 2014 at 21:21 UTC
Jump to comment: Most recent
Comments
Comment #1
nod_oups :p
Comment #2
lars toomre commentedThe theme_table() functions needs a docblock.
Comment #3
steveoliver commentedLet's postpone this on #1778968: Convert theme_table to Twig getting into core?
Comment #4
sunmmm, I'm a little scared by doing such fundamental refactoring as part of a monster branch/patch that will change a ton of other things.
Furthermore, I looked at the patch in #1778968: Convert theme_table to Twig and it looks like it doesn't really improve the situation with
theme_table()- the total amount of conditional and custom processing per table/thead/tbody/row/column/cell is only increased, it's partially moved into the templating layer, and the sandbox-committed code contains a range of @todos that were not addressed.Now that #80855-90: Add element #type table and merge tableselect/tabledrag into it has landed, I think we can and should move forward with this clean-up here. (Also note the follow-up issues mentioned over in comment #90.)
In essence, most of
theme_table()should be moved into atemplate_preprocess_table()that performs all of the heavy plumbing, so thattheme_table()itself turns into a couple of pure + trivial foreach loops that render the individual parts. In terms of complexity,theme_table()(as well as table.twig.html) should look almost identical in the end and should not contain any special conditions or manual processing in the default theme implementation anymore.Comment #5
sunComment #6
sun#1939008: Convert theme_table() to Twig made this obsolete.