Horizontal extensibility of Fields: introduce the concept of behavior plugins

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.

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.

I'm going to have a stab at this.

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

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?

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

Quite possible, but only after #1969728: Implement Field API "field types" as TypedData Plugins.

Update example links.

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?

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

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.

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

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

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.

@andypost can you point me to an example for such a pattern. My goal is to have a understanding on how to port Entityreference-prepopulate module to D8

I'm also very interested in this. I can confirm that a good horizontal extensibility like entityreference provided is a *huge* win for field behavior contrib modules.

@amitaibu, @andipost: So the idea is to swap out the field handler against a loosely coupled one that delegates most methods simply to the original handler (and in the case of multiple behaviors we'll get a delegation chain) like outlined here.
What i did *not yet* grok is, where is the swapping-out-and-decorationg of the field handler happening?

(Note-to-self: Check if the decorate-and-delegate boilerplate code might live in a reusable trait.)