Problem/Motivation

Field API provides the concepts of Field, Widgets, and Formatters types. With the ongoing conversion of the Field API as plugins, those are becoming vertically extensible. It's going to become relatively easy to build a Field type that derives from another Field type (an obvious example of which is Image Field vs. File Field in core).

The Field API would benefit from being horizontally extensible as well. In Entity Reference in Drupal 7 we introduced the concept of "Behaviors": you can extend the Entity Reference field type with multiple additional behaviors. Example of which:

In essence, the behavior provides a nice encapsulation and an UI for interacting with a Field type and the lifecycle of the data it stores. Everything that currently implements hook_field_attach_*() could be a candidate to become a Field Behavior.

Proposed resolution

Implement the concept of "Field Behavior" plugins. Those plugins can be attached to a field or instance either via its definition or via the Field UI, and participate to many events in the lifecycle of a field and/or instance.

In detail, a "Field Behavior" plugin satisfies the following:

  • A behavior plugin can be field-level, instance-level or both.
  • One or more behavior plugin can be enabled on each Field.
  • One or more behavior plugin can be enabled on each Field instance.
  • A behavior plugin participates in the Field and instance settings form provided by the Field UI.
  • A behavior plugin can alter the Field schema.
  • A behavior plugin can alter the Field property information.
  • A behavior plugin can participate in the Field data lifecycle (load, is empty, validate, presave, insert, update, delete)
  • A behavior plugin can participate in the Entity data lifecycle of entities its field is attached to (load, presave, insert, update, delete)
  • A behavior plugin can decide if it can be applied to a particular field or field instance.

User interface changes

The Field and Field instance settings form will have an additional section for behaviors. The current UI in Entity Reference can be used as a blueprint, but will require usability review.

API changes

This will not introduce any API change. The following additions:

  • The "Field Behavior" plugin type
Files: 
CommentFileSizeAuthor
#9 behaviors-1803064-9.patch14.85 KBamitaibu

Comments

andypost’s picture

By the first look tree.module seems over-engineering and I think it's not a good example. Also all ER modules are very fragile and seems has low attention from maintainers - all of them are alpha and has a lot of unresolved issues.

Also we already have a kind of behaviors in core (a js) so it could lead to another confusion like #1803630: Rename entity bundles to avoid confusion

EDIT core now ships with a Decorator plugins which makes more sense from UX

moshe weitzman’s picture

Do we port formatters and widgets to be behaviors? I'm not quite sure how those fit in. Those are currently nice, understandable concepts IMO.

Damien Tournoud’s picture

Do we port formatters and widgets to be behaviors? I'm not quite sure how those fit in. Those are currently nice, understandable concepts IMO.

No, I think we want formatter-level and widget-level behaviors too, so that you can alter / extend formatters and widgets the same way.

amitaibu’s picture

Everything that currently implements hook_field_attach_*() could be a candidate to become a Field Behavior.

I think maybe we can take it one step further and actually remove hook_field_attach_*() in favor of behavior plugins?

Also all ER modules are very fragile and seems has low attention from maintainers

OG and Entity-reference pre populate are properly --or so I hope :) -- maintained, and they both rely on the "Behaviors". I have also updated the example links in the issue summary.

Also we already have a kind of behaviors in core

How about "field-behavior"?

fmizzell’s picture

In eck, we also have behaviors for what used to be called properties (now they are also called fields). Could that be part of this issue, since we are trying to unify field api and non-filed-api fields?

mitchell’s picture

Observations:

  1. This functionality and name pattern dovetails #1302378: Use multiple specialized entity controllers nicely, ie. "field controllers".
  2. If "behaviors" or another name is changed after development, it would likely follow #1807042: Reorganizie entity storage/list/form/render controller annotation keys.
  3. The existing documentation for ECK property behaviors and code for author, changed, created, language, and title && machine_name and published could also help flesh this out.
  4. While discussing with fmizzell how #1821870: Create a UI for managing entity types could radically change node module, he said, "it would be some major work to turn everything that node does, into behaviors.. it would be worth it though. [...] it would have to be everything that is functionality: publishing, the created, and changed automations that happened behind the scenes, assigning the logged in user as the author. eck already does most of that, but to get rid of node, you will have to have those behaviors so people can recreate node from any other entity type they create"
  5. Another use case I would like to request some feedback on is the encryption/decryption of a user password or other fields with an available algorithm.
amitaibu’s picture

Assigned: Unassigned » amitaibu

I'm going to have a stab at this.

amitaibu’s picture

Work is done in yched's sandbox, in branch behaviors-1803064

amitaibu’s picture

Status: Active » Needs work
FileSize
14.85 KB

WIP, but having progress. No UI yet. Brave ones can test:

  • Enable "field_test" module.
  • Add $field['settings']['behaviors']['field_test']['status'] = TRUE; to a select-list field.
  • Submit a new node, and see how the isEmptyAlter() is invoked from _field_filter_items().

I've added a todo about should we keep for example in _field_filter_items() calling the dummy-hook (i.e. a single function), or should we move everything to behaviors. (And to answer myself, at least for the beginning we should keep the older dummy-hooks).

andypost’s picture

As ER in - is this feature for D8?

amitaibu’s picture

Assigned: amitaibu » Unassigned

Un-assigning until I get more than 2-3 hours sleep a night ;)
@amateescu, any chance your going to work on it? The community, OG and ER-prepopulate would be grateful ;)

amateescu’s picture

amateescu’s picture

Issue summary: View changes

Update example links.

mccrodp’s picture

I made a minimal start on #2615320: [entityreference_prepopulate] Entityreference prepopulate and ran into this issue relating to entity reference behavior plugins.

@amitaibu / anyone else: what is the status of this re: entity reference behavior plugins and does it block a entityreference_prepopulate release for example?

amitaibu’s picture

> and does it block a entityreference_prepopulate release for example?

It probably will require some re-thinking on how to do it, since indeed behavior plugins don't exist in D8. Not sure myself yet what would be the best approach..

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

axel.rutz’s picture

This would be great! Rock on!

Minor:

  1. +++ b/core/modules/field/field.module
    @@ -574,6 +576,55 @@ function field_get_plugin_manager($plugin_type) {
    + * Get the behavior handlers for a given entityreference field.
    

    Leftover from entityreference.

  2. +++ b/core/modules/field/lib/Drupal/field/Plugin/Type/Behavior/BehaviorInterface.php
    @@ -0,0 +1,133 @@
    +   * @see entityreference_field_views_data()
    

    Also.

joelpittet’s picture

I wonder how this related to what @andypost said in #1 about Decorators being in core. That pattern seems like it may be a good fit here in my off the cuff reaction.

core now ships with a Decorator plugins which makes more sense from UX

webchick’s picture

Version: 8.1.x-dev » 8.3.x-dev

Just moving a feature to 8.3.x. (Weird the scripts didn't auto-do this.)

andypost’s picture

Decorator is only available pattern for fields now, I think *behaviors* will bring huge overhead to performance so better to beware calling entity-hooks for "field-extensions" - better to "decorate" field or widget/formatter.