Is there a reason this module stores the display information on the field management side instead of the display side? It would allow us to use different formats for teasers and full, etc. Im just getting dug in with the module but i was surprised to find it where i did as manage field usually has to do with field storage (schema) and data entry (widget).

Comments

jensimmons’s picture

Status: Active » Closed (works as designed)

Yes, there is a reason. We debated this for quite a long time when this module was first born. There are a few other Drupal contrib modules that take the other approach — asking the site building to configure the element for each display separately. But we concluded there are several problems with that approach:

1) It's a lot of work to have to configure the element each and every time a field is displayed. It's already hard to get the Drupal developers on the team (those who are creating content types) to take a moment, think about semantics (yes, web standards are important!), and choose the proper element for each field. If those developers had to do so over and over again for the same fields, it's unlikely that they would. It'd be too easy for things to get inconsistent very quickly.

2) Semantics don't change from display to display. If a certain field is a figcaption, it's always a figcaption. It should be a figcaption everywhere, no matter whether it's on the full node display, a teaser display, in a view list… it's a caption for a figure. We believe the content and the semantics of that content should be welded together. The approach of Fences accomplishes that task, and helps enforce such definitions.

If you do have a use case where you need "different formats for different displays", you can look into the other modules (who's names aren't coming to mind right now, since I never use them, sorry).