Issue #1875974 by swentel, andypost, yched, amateescu aspilicious: Abstract 'component type' specific code out of EntityDisplay.
The EntityDisplay class introduced inincludes hardcoded logic to handle "field" and "extra field" components.
- It currently only deals with "Field API field" & "extra field" (aka arbitrary render array snippet) components. There is hardcoded logic to determine which is which and how to handle each.
--> Contrib "component types" are currently not possible, and it's very much needed for Display Suite / Field groups.
The entity render flow is based on the fact that a single EntityDisplay object, loaded and altered once as a whole, contains the whole "display recipe" for an entity in a given view mode. Display suite / Field groups need to be able to participate in that flow.
- Now that widgets / formatters are theoretically usable on "base fields", EntityDisplay objects are the natural (and only) place to store widget / formatter configuration on base fields.
They thus need to be uncoupled from the notion of "configurable Field API field" (i.e field_info_*() API calls)
If we want EntityDisplay objects to hold display options for every component in a entity view, including contrib stuff like field_groups, the EntityDisplay methods should be agnostic about what type of "thing" they contain (field, 'extra field', field_group, possibly blocksNG...), and the "component-type" specific logic needs to be split out into pluggable handler classes.
Thus, EntityDisplay objects become a collection of configured plugins, which is a well known pattern.
- Component types are plugins.
- Each component type ("field API field", "extra field", "field_group", ... possibly "block") has a handler class (one object of each is enough for the whole request).
- The EntityDisplay defers handling of setComponent() / getComponent() methods to the relevant component type handler, and just stores the result (i.e no more massaging code specific to fields or extra fields in EntityDisplay methods).
- the entity display config entities store the additional 'component type' property in each entry.
API Changes (D8 only - this whole API is new in D8)
- Introduce "entity display component" plugin type (API addition + is only of interest for very few contrib modules)
- the [get/set]Component(s) methods receive an additional parameter, the 'component type', (plugin id of one of the above plugins) - e.g. 'field' for configurable fields, 'extra_field' for extra fields, 'field_group' for field groups...
This changes all existing setComponent() calls (mostly used in tests). The function could possibly default the 'component type' to 'field', keeping most existing calls working.
Work happens in http://drupalcode.org/sandbox/yched/1736366.git/shortlog/refs/heads/1875... - helper issue is over at -
http://drupalcode.org/sandbox/yched/1736366.git/shortlog/refs/heads/enti... (old branch)