Drupal Association members fund grants that make connections all over the world.
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.
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).
- 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 without hacks.
- This is required for doing - what should bring a nice memory usage improvement.
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.
- 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 - 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 we can move to an adapter approach instead of using inheritance here as well.
Performance tests have been run, see comments #117 & #118.
PASSED: [[SimpleTest]]: [MySQL] 59,087 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 59,121 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 59,128 pass(es), 1 fail(s), and 2 exception(s). View