Jump to:

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.

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.

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?

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"

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.

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