Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
asset library system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
15 Jan 2014 at 05:13 UTC
Updated:
29 Jul 2014 at 23:16 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jessebeach commentedThis patch cleans up
theme_tableandtheme_tableselect.I'm still working on
template_preprocess_htmlsetDialogTitleviews_preprocess_pageComment #2
wim leersI'm afraid I've found many flaws in this patch :(
You're always attaching the tableselect library, whereas before it was only conditionally added!
Moving this from
theme_table()todrupal_pre_render_table()is going to break things AFAICT: not everytheme_table()call is going to result in a call todrupal_pre_render_table()!I think this is incorrect: this explicitly tests
#theme => table, yet you're moving it to#type => table…Same here.
Comment #3
jessebeach commentedRight, this was intentional. Maybe not the best choice, but intentional in order to avoid having to add a pre_render function in which the inclusion of the library would be toggled. Since the default of the element is to include the select all checkbox, the element just includes the associated JS file by default as well. As I was discussing this issue with Moshe, he was advocating for less complex code at the cost of flexibility. I don't think I've struck that balance well yet, as you pointed out.
No direct call to
theme('table', array())will result in a call todrupal_pre_render_table. That's because callingtheme()directly steps into middle of the build process and skips crucial steps. As I was working on this issue, this became more and more apparent. It's ultimately why I opened #2173655: Refactor theme() to _theme(); make it a private API to discourage module developers from circumventing the renderable build system. If we don't discourage direct calling oftheme(), then we can't avoid callingdrupal_render()in theme functions because we can't rely ondrupal_process_attachmentsbeing called on a renderable.Sure, agreed. I think we're ultimately abusing
theme_table()here. If flags to the theme function can vary included resources, then we can't simply call theme directly as the build process currently stands because this function isn't structured to handle outside resources; it simply turns variables into printable strings.Wim, thanks for the feedback. Given your take, I think we need to postpone this issue on #2173655: Refactor theme() to _theme(); make it a private API to discourage module developers from circumventing the renderable build system. Your original approach to #2171071: Rename drupal_add_library() to _drupal_add_library() and remove its uses was appropriate given the current state of the render pipeline and we can't make meaningful refactoring changes unless we privatize
theme()first.Comment #4
jessebeach commentedPostponed on #2173655: Refactor theme() to _theme(); make it a private API to discourage module developers from circumventing the renderable build system
Comment #5
webchickReverted #2171071: Rename drupal_add_library() to _drupal_add_library() and remove its uses, so let's deal with this over there.