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

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

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.

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.

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"?

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?

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.

Assigned:Unassigned» Amitaibu

I'm going to have a stab at this.

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

Status:Active» Needs work
StatusFileSize
new14.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).

As ER in - is this feature for D8?

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 ;)

Issue summary:View changes

Update example links.