Timeline for how to get view_mode from within hook_field_formatter_view
Current License: CC BY-SA 3.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Mar 14, 2015 at 12:31 | answer | added | gifad | timeline score: 0 | |
Aug 11, 2012 at 4:47 | vote | accept | cherouvim | ||
Aug 10, 2012 at 12:15 | comment | added | Andy | Done, hope it's not too copy & paste (: | |
Aug 10, 2012 at 12:14 | answer | added | Andy | timeline score: 1 | |
Aug 10, 2012 at 9:32 | comment | added | cherouvim | @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. | |
Aug 8, 2012 at 8:21 | comment | added | Andy |
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...
|
|
Aug 7, 2012 at 19:05 | comment | added | cherouvim | @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? | |
Aug 7, 2012 at 16:02 | comment | added | Andy | 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. | |
Aug 7, 2012 at 15:57 | history | asked | cherouvim | CC BY-SA 3.0 |