With the entity field API we've got a new underlying API for entity fields, which field API implements as well. In this issue we'll keep track of ongoing re-factorings to make both APIs work well together and removing unnecessary duplications. This is a meta-issue to keep track of step 4 of #1346214: [meta] Unified Entity Field API.

Issues / tasks:
- #1969728: Implement Field API "field types" as TypedData Plugins (and base them on entity field item classes ?)
- #1497374: Switch from Field-based storage to Entity-based storage
- #1950632: Create a FieldDefinitionInterface and use it for formatters and widgets
- #1994140: Unify entity field access and Field API access
- #2050801: Unify handling of default values between base and configurable fields

Terminology:
- Entity field -> everything on an entity (node title, node body, node tags, ..)
- Configurable field -> a field API field (also see #1798140: Agree upon terminology for configurable fields).

Comments

alex, berdir and yched and me had a hang-out discussing this quite a bit. Here's the google doc we used to write down some notes: https://docs.google.com/document/d/1nXwKtFYfKLrCLy4pkxzoxfYteSkIIUF1QI0w...

I try to shortly summarize it here:

Field types as plugins

  • We already have field item classes and field classes for each field type for the entity field API, i.e. classes for $node->body and $node->body[0].
  • For DX it would be good if developers would have to expose only one class in order to provide a new field type.
  • Entity field / field item classes could be extended with a configurable field interface holding necessary additions needed by the field API, e.g. like getSchema(), insert(), update() "hook", ...
  • Problem are methods/callbacks for multiple handling like load() and prepare_view(). One possible idea is to off-load them to an optional multiple handler as most field types don't require them anyway.

Improve formatters and widgets to make them usable with all fields

  • Formatters and widgets depend on field API $field and $instance data structures, so currently we cannot use them with entity fields.
  • We don't want to require config entities for base entity fields defined by the entity type (node title, node language, node nid, ..) as those are critical for the entity type to work, so it should not depend on any CMI files to be there and everything be in sync. (Not mentioning field configs are entities as well ...)
  • We discussed multiple options for making formatters and widgets work independently from field instances and $field. We figured out that formatters and widgets mostly rely on instance settings and field settings plus some foundational field information. After discussing separate proxy objects, mappings etc. we figured that a merged representation of the field and instance object would cut it. Fortunately, we could serve that via the entity field object $items as we can merge settings in its getDefinition() method, e.g. see this code snippet:

    <?php
    class Formatter {
      function
    render (FieldInterface $items) {
        
    // getDefinition() of a configurable field would merge instance and field settings,
         // while an entity field would just have to take care to provide the necessary settings.
        
    $definition = $items->getDefinition();
        
    $default_value = $items->getDefaultValue();
        
    $settings = $definition[‘settings’];
        
    $cardinality = $definition[‘cardinalty’];
      }
    function
    settingsForm($definition) {
    }
    }
    ?>

    That way, an entity field that wants to make use of a field formatter or widget would just have to make sure it has the necessary settings in place also. Formatters and widgets still explicitly state which field types they support.

Move field storage to entity storage

See #1497374-37: Switch from Field-based storage to Entity-based storage

Issue tags:+Entity Field API

Issue summary:View changes

Updated issue summary.

Issue tags:+Spark

Thanks for this issue and #1950632: Create a FieldDefinitionInterface and use it for formatters and widgets. That really helps in getting a clear handle on this :)

Opened #1969728: Implement Field API "field types" as TypedData Plugins, and added it to the issue summary.

Issue summary:View changes

Opened issue for formatter/widget changes, and added it to summary

Issue summary:View changes

Added issue link

Opened #1994140: Unify entity field access and Field API access and added it to the issue summary.

Issue summary:View changes

Updated issue summary.

Status:Active» Fixed

Cleanup up the meta issues, will move the two remaining issues to the parent meta issue (which is also a child meta of another meta :))

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

added 2050801