In the core developers summit at DC CPH, jensimmons brought up the issue that some developers include markup in code that isn't processed through a theme function, which makes it hard for themers to change. Crell stood up and said that these instances should be filed as bugs.
I think that field_example_field_formatter_view() would be one of those instances. For example, the following line should use a theme function instead of a string.
$element[$delta]['#markup'] = '<p style="color: ' . $item['rgb'] . '">' . t('The color code in this field is @code', array('@code' => $item['rgb'])) . '</p>';
Comments
Comment #1
rfayWorks for me, especially in an example like this.
Comment #2
Anonymous (not verified) commentedComment #4
mile23git-generated diffs need the --no-prefix setting.
Comment #5
Anonymous (not verified) commentedAhhhh... the more you know :) Thanks Mile23
Let's give this a shot....
Comment #6
rfayWouldn't it be better to use a 'render element' type theme function, and then to use #attached to add the CSS on?
Comment #7
ilo commentedLinkclark, do you have any advance on this issue? if you are not going to work on it please, remove the assignment so other can pick it up.
Comment #8
Anonymous (not verified) commentedComment #9
Anonymous (not verified) commentedI've been playing around with this tonight, I haven't taken much time to play around with the Render API up until now, so I'm running into a few things that confuse me.
When you say to use a 'render element' type theme function, do you mean having the theme function declared like the following?
Because when I do that, theme_field is no longer used at all, so the label logic in theme_field would need to be duplicated.
Is there another way to declare the render element type theme function?
Comment #10
mile23I thought the idea with hook_field_formatter_view(), and D7 in general, was to return a renderable array, not themed output, so that themes could then muck about with them all they want.
#attach seems to be for file-based styles, and we just want to set the items color, not load in a whole new rule set.
#attributes looks like a likely candidate but it doesn't work.
That leaves us with #prefix and #suffix, which seem a little redundant.
Comment #11
mile23Comment #12
Anonymous (not verified) commentedI've just been reading through Field Attach API source code and I think you are right about using prefix/suffix as opposed to a theme function, Mile23. I think that using #prefix and #suffix is good to show because it demonstrates how developers can give themers the ability to change out the elements that are used around the content itself.
In the drupal_add_css docs, it says that using the 'file' type is better practice because then the styles are aggregated and cached. I think it is also a better practice because it allows for just that file to be removed or replaced before rendering if need be.
Comment #13
Anonymous (not verified) commentedMeant to change to needs work.
Comment #14
Anonymous (not verified) commentedActually, I think I may have figured this out.
I think that this should be a render element of type html_tag kind of like the following
Comment #15
mile23That's got it, linclark. :-) The magic secret is documented here: theme_html_tag()
I'd change the 'field_example_color_background' type similarly, but I can't find how it's implemented to test it.
Comment #17
Anonymous (not verified) commentedsweeeet! I'll take a look at the field_color_background later today
Comment #18
mile23Hmm.. the test will have to be rewritten too, it looks like.
Comment #19
Anonymous (not verified) commentedI didn't look at the tests, but I think this may have failed because it used to be a
<p>tag.I changed the first example back to a p, made the comment a little shorter, and created the render array for the background example. It turns out that you can use #attached with inline css.
Comment #20
dave reidComment #21
rfayLooks good to me. I think a final edit should remove some trailing whitespace.
Comment #22
rfay#19: d7_field_example_1021194_19.patch queued for re-testing.
Comment #24
rfayCommitted with minor formatting changes. Outstanding work, and sorry for the painful wait.
I tested manually and it seemed fine.
D7: 3f91a94
D8: 26287a4
Comment #25
rfayAnd a followup:
Field titles don't show in field example; Improve field_example_tests
In the process of working on this one I noticed that the regular (textfield and colorpicker) field widgets lose the #title attribute in the current code, so the field shows no title.
Since I was working on the plane I didn't want to create a new issue, so doing this as a followup here.
This patch also adds tests for the textfield and colorpicker fields, and cleans up the tests so they're not so redundant.
D7: 73e0577
D8: 6dcc461