Voting starts in March for the Drupal Association Board election.
The whole point of
and more generally ,
has been to unify base fields and configurable fields by:
- having the same set of supporting code (field type classes)
- then being able to use applicable widgets and formatters on them based on those field types.
We have everything in place to do that, and in the conversions from "old Field API field types to new EntityNG field types" currently under way, we make sure that field type classes are agnostic about "base or configurable" fields and can be used on both.
But we need to decide who will provide those "field type" classes if we want to use them for base fields in core entity types.
Take email field, for example. In current HEAD, there is:
- Drupal\Core\Entity\Plugin\DataType\EmailItem (provided by Core/Entity), exposed as a the 'email_field' DataType plugin.
This is used for the 'mail' "base field" of contact.module's Message entities (but oddly enough not for User 'mail' for now)
- email.module, that still uses the legacy hook_field_info() to expose the 'email' FieldType, which is then derived to the 'field_type:email' DataType.
Moving this to the new "field type API" means exposing a new class implementing FieldItemInterface, but also ConfigurableFieldItemInterface so that this can be used as a "configurable field".
How do we do that ?
1) email.module provides ConfigurableEmailFieldItem, extending Core's EmailItem ?
This is what currently does (see #19-#21 over there).
We bloat our "field type plugins" registry with two separate field types, one for base fields, the other for configurable fields.
Then widgets & formatters need to explicitly account for both ("I work on 'email' and 'configurable_email' field types").
Repeat that for all the field types we might want to use in base fields (text, number, maybe even link and entity_ref...).
This is kind of silly, since the only thing in ConfigurableEmailFieldItem is the schema() method. One single class / one single field type could totally work indifferently on base fields and configurable fields. That's the whole point of the abstract FieldDefinitionInterface.
If "two separate sets of field types for base or configurable fields" is where we end up, I'd say we haven't unified anything...
2) Remove Drupal\Core\Entity\Plugin\DataType\EmailItem,
email.module provides Drupal\email\Plugin\field\field_type\EmailItem as the 'email' field type,
The 'mail' field in Message entities 'mail' field uses 'type' => 'field_type:email'
This means contact.module has a dependency on email.module - or more generally, modules providing entity types require the modules that provide the field types they want to use for their base fields. Well, this only seems reasonable?
Are we OK with having contact.module, node.module, user.module... require text.module, number.module, email.module, maybe entity_ref.module... ?
Means those modules are de-facto required on all sites.
3) Remove email.module,
add everything it takes to be used for configurable fields in the EmailItem provided in Drupal\Core\Entity.
This means shipping "basic" field types in the Drupal\Core package rather than in standalone modules.
Granted, once the field type, the widgets, the formatters are in plugin classes, there's not much code left in email.module, number.module, etc. There's a little more in text.module, and much more in entity_reference.module.
- Where is the line ? is "text" basic ? what about "file", "image", "entity_ref" ?
- This means Drupal\Core has classes that extend ConfigurableFieldItemBase, which is currently provided by field.module
- Then we also need to move along the widgets and formatters plugins provided by the former separate modules ?
How do we organize that ? The annotation discovery forces "all field types in a folder, all formatters in a folder, all widgets in a folder". Given that some of them use base classes, that's a lot of classes blended together...