#1950632: 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
- There is only one sort of field definition really, less confusion, better DX, better compatiblity.
- Something like his is required to do #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title
without hacks.
- This is required for doing #2116363: Unified repository of field definitions (cache + API)
- what should bring a nice memory usage improvement.
Changes:
Entity field definitions become objects, with a BC layer (for non-configurable fields) 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
More detailled list/summary of changes:
- Adds DataDefinition, ListDefinition classes and according interfaces for typed data definitions
- Lists are defined using separate data definitions now, as suggested by #1928938: Improve typed data definitions of lists
- so list definitions and list item definitions are now clearly separated what cleans up a few things.
- Added FieldDefinition class for entity fields, based upon the list & data definition classes.
- Made classes + typed data manager work with the definition objects. For BC definition objects provide array access for now. TypedConfig still uses definitions as arrays and needs to be cleaned up in a follow-up.
- Field definitions and data definitions are still defined using arrays for now, but converted to objects once they have been picked up. That eases migration.
- Taxonomy term, string item and integer item field/data definitions has been converted as DX example.
- $this->definition in typed data objects is the data definition now, what for entity fields is the field definition. However, what's a bit confusing for field instances right now is that $this->definition will be the general non-bundle specific entity field definition, while getFieldDefinition() returns the "instance definition". This will be fixed with the follow-up of allow per-bundle field definitions in the entity field api (see todos).
- Thus, for configurable fields $this->definition is the field config entity (but should become the field instance later on).
- FielddefinitionInterface extends from DataDefinitionInterface (for now), so configurable field definition objects are data definitions as well - what removes the need to map them to yet another format. With #2002138: Use adapters for supporting typed data
we can move to an adapter approach instead of using inheritance here as well.
Performance tests have been run, see comments #117 & #118.
Follow-ups:
#2112239: Follow up: Convert and clean base field definitions.
#2114707: Allow per-bundle overrides of field definitions
#2116341: Clarify how classed definition objects deal with defaults
#2116347: Move FIELD_CARDINALITY_UNLIMITED constaint to the Field definition interface
#2116363: Unified repository of field definitions (cache + API)
#2120373: Optimize performance of class based field definitions
#1928868: Make typed config valid typed data
#2143555: Improve how field definitions deal with dependencies and testing
#2143263: Remove "Field" prefix from FieldDefinitionInterface methods