#1497374: Switch from Field-based storage to Entity-based storage introduced dependencies on classes / interfaces provided by field.module in the storage controller classes.
See the use statements at the top of:
core/lib/Drupal/Core/Entity/FieldableEntityStorageControllerInterface.php
core/lib/Drupal/Core/Entity/FieldableEntityStorageControllerBase.php
core/lib/Drupal/Core/Entity/DatabaseStorageController.php
core/lib/Drupal/Core/Entity/DatabaseStorageControllerNG.php
But even before the "entity storage" patch:
- core/lib/Drupal/Core/Entity/Query/Sql/Tables.php (EFQ) depends on Drupal\field\Entity\Field
- many methods in Core/Entity* classes already include direct function calls to field_* functions
field_available_languages()
field_is_translatable()
field_has_translation_handler()
field_read_instances()
field_info_instances()
field_info_extra_fields()
field_form_get_state() / field_form_set_state()
field_invoke_method()
field_attach_form*()
field_attach_view*()
So Core/Entity is pretty coupled with field.module right now.
Tasks
Some of the tasks I see here:
- Field multilingual logic
(Will probably be cleaned after #2019055: Switch from field-level language fallback to entity-level language fallback and #2067079: Remove the Field Language API)
- A unified API to get lists of "field definitions" (base, configurable, or both) - with persistent and static caching.
That's basically merging FieldInfo and EntityManager::getFieldDefinitions(), which are currently two separate APIs with separate cache logic.
- #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title, and what it means for entity form/render controllers
- Entity storage & base fields - FieldableEntityStorageControllerInterface & associated base class only take care of configurable fields. How to manage tables for base fields, defined in code, is an enigma to me, they have no observable CRUD cycle to react to.
- "extra fields" - moving those to the entity system was rejected as an API change for D8 (#1954188: Revaluate the concept of 'extra fields')
As a side note: It's very possible IMO that the notion of "configurable fields" (the current FieldInterface / FieldInstanceInterface) might need to move into Core/Entity, with field.module providing the actual implementations and config entities.
In short: making Core/Entity independent on field.module is definitely a good architectural target, but it's still wishful thinking atm, and I'm quite unsure we'll get there for D8. IMO, that is annoying from an architectural purity POV, but not critical either.
*Some* of the tasks above are important and will probably need to happen. But complete uncoupling is not something that I plan to personally prioritize in itself for the rest of the D8 cycle.