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

rfay’s picture

Works for me, especially in an example like this.

Anonymous’s picture

Status: Active » Needs review
StatusFileSize
new3.58 KB

Status: Needs review » Needs work

The last submitted patch, examples-field_example_theme-1021194-2.patch, failed testing.

mile23’s picture

git-generated diffs need the --no-prefix setting.

Anonymous’s picture

Status: Needs work » Needs review
StatusFileSize
new3.57 KB

Ahhhh... the more you know :) Thanks Mile23

Let's give this a shot....

rfay’s picture

Status: Needs review » Needs work

Wouldn't it be better to use a 'render element' type theme function, and then to use #attached to add the CSS on?

ilo’s picture

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

Anonymous’s picture

Assigned: linclark » Unassigned
Anonymous’s picture

I'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?

    case 'field_example_simple_text':
      $element['#theme'] = 'field_example_simple_text';
      break;

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?

mile23’s picture

Status: Needs review » Needs work
StatusFileSize
new1.22 KB

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

mile23’s picture

Status: Needs work » Needs review
Anonymous’s picture

Status: Needs work » Needs review

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

Anonymous’s picture

Status: Needs review » Needs work

Meant to change to needs work.

Anonymous’s picture

Actually, 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

  $elements['system_meta_content_type'] = array(
    '#type' => 'html_tag',
    '#tag' => 'meta',
    '#attributes' => array(
      'http-equiv' => 'Content-Type',
      'content' => 'text/html; charset=utf-8',
    ),
    // Security: This always has to be output first.
    '#weight' => -1000,
  );
mile23’s picture

Title: use theme function for #markup » Use theme function for #markup
Status: Needs work » Needs review
StatusFileSize
new1.44 KB

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

Status: Needs review » Needs work

The last submitted patch, d7_field_example_1021194.patch, failed testing.

Anonymous’s picture

sweeeet! I'll take a look at the field_color_background later today

mile23’s picture

Hmm.. the test will have to be rewritten too, it looks like.

Anonymous’s picture

Status: Needs work » Needs review
StatusFileSize
new2.44 KB

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

dave reid’s picture

Version: » 7.x-1.x-dev
rfay’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me. I think a final edit should remove some trailing whitespace.

rfay’s picture

#19: d7_field_example_1021194_19.patch queued for re-testing.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, d7_field_example_1021194_19.patch, failed testing.

rfay’s picture

Committed with minor formatting changes. Outstanding work, and sorry for the painful wait.

I tested manually and it seemed fine.

D7: 3f91a94
D8: 26287a4

rfay’s picture

Status: Needs work » Fixed

And 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

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.