0

I've created a custom field formatter which works correctly. My problem is that I want to differentiate its output depending on whether it's being used in a default or teaser view mode.

The hook_field_formatter_view doesn't seem to provide this.

One way I can solve this is by providing a setting on that formatter (hook_field_formatter_settings_form) with possible values default and teaser. I'd then have to go to the teaser view mode of all content types and configure this setting on all uses of that formatter. I'd then be able to get the setting using $display['settings']. This would work but it's a bad solution since it would be replicating data that is already there and it also requires administrative work.

Is there a cleaner solution to this?

5
  • 2
    Imho a formatter shouldn't be dependent on the view mode. It's the site builder's choice which formatter to use in which view mode, and through that decide how things look. It sounds to me like you'd be better off either having two formatters, or having one formatter which can be configured.
    – Andy
    Commented Aug 7, 2012 at 16:02
  • @Andy, OK. In that case, why does hook_field_formatter_settings_form have a $view_mode param? Why should the settings of a formatter be view_mode aware but the formatter itself not aware?
    – cherouvim
    Commented Aug 7, 2012 at 19:05
  • I'm afraid I can't answer that authoritatively but certainly $instance['display'] is keyed by view mode, so for that alone it's necessary. My understanding of the Drupal way here is that you provide the general purpose tools (just like a module typically provides permissions, but not a new role - leaving it to the site builder to aggregate perms into roles appropriate for their particular needs). Every time I create a new view mode I want to have complete power to make it do exactly what I want. My 2 pennies...
    – Andy
    Commented Aug 8, 2012 at 8:21
  • @Andy, OK got it. It makes sense. So I solved it with a setting. Feel free to formulate your comment as an answer so I can accept.
    – cherouvim
    Commented Aug 10, 2012 at 9:32
  • Done, hope it's not too copy & paste (:
    – Andy
    Commented Aug 10, 2012 at 12:15

2 Answers 2

1

Imho a formatter shouldn't be dependent on the view mode. It's the site builder's choice which formatter to use in which view mode, and through that decide how things look. It sounds to me like you'd be better off either having two formatters, or having one formatter which can be configured.

My understanding of the Drupal way here is that you provide the general purpose tools (just like a module typically provides permissions, but not a new role - leaving it to the site builder to aggregate perms into roles appropriate for their particular needs). Every time I create a new view mode I want to have complete power to make it do exactly what I want.

1
  • 1
    While I generally agree, I just now run into a case where I want the view mode for error reporting in watchdog. I want to log that something went wrong in the formatter, and where this happened.
    – donquixote
    Commented Jan 14, 2017 at 23:01
0

Not sure this can be qualified as "cleaner" code, but looking at field_default_view source code, I can get the original view mode by :

function my_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  $backtrace = debug_backtrace(TRUE);
  $view_mode = $backtrace[1]['args'][6];

You can use Devel to confirm this…

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.