#1950632: Change notice: Create a FieldDefinitionInterface and use it for formatters and widgets established a new interface for field definitions which is intended shared between configurable and non-configurable entity fields. As of now, it's only implemented for configurable fields though.
#1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title started using existing entity field definition arrays and creating field definition classes from that, however I think that could become quite confusing as we'd end up with field definitions on the entity level being defined as arrays while we have an entity level field definition interface and field definition classes in most other places (widgets, formatters,..).
So, instead of having that confusing separation between two different kinds of field definitions I think we should do just one class based field definition which can suit all our needs.
As entity field definitions are just typed data definitions, consequently those must become classes as well.
So this changes how entity base fields gets defined, but I think it becomes way easier using the class based notation (todo: implement and show example here).
Advantages:
- Allows dealing with entity field definitions and configurable field definitions the same way - natively.
- Better DX when defining entity fields
- Better documentation of data/entity field definition keys and application of default values
- Typed data definitions become objects also what makes it more
This helps with
- #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title
- #1497374: Switch from Field-based storage to Entity-based storage to let it work based upon entity-field interfaces (API separation).
- #2023563: Convert entity field types to the field_type plugin - we can avoid further API changes as necessary field definition changes can become internal only
Open points
- FieldDefinitionInterface should probably extend from DataDefinitionInterface, but how do configurable fields implement that best? Should we directly implement it and just cache the full config-entities with the entity-field-definitions or should we create a new definition object for that?
- Do we need to keep BC for 'list_class' and data definitions as arrays?
Changes:
Entity field definitions become objects, with a BC layer to support existing array structures.
Typed data definitions become objects, with a BC layer to support existing array structures.
#1928938: Improve typed data definitions of lists - the OO-interface already accounts for that and properly separates list and list-item related keys