In D7, if you want to add any non-field mechanics to entities, you have to implement a number of modules, including hook_form_alter(), and stuff like hook_node_update(), etc.
Within these hooks, you need to examine the given entity and check whether your mechanic is actually enabled for this entity bundle.
This all kind of works, but it is ugly and fragile.
- Url aliases and redirects
- Menu items for nodes
(I'm sure there are more examples)
Modules can attach behavior objects to an entity type. Those behavior objects can subscribe to a number of events related to this entity type.
Especially, they can
- do something if an entity is created, updated, etc.
- do something if a bundle for this entity type is created, updated, etc.
- declare bundle options (see below)
Modules can attach behavior objects to an entity bundle. Those behavior objects can subscribe to a number of events related to this entity bundle.
Especially, they can
- provide form elements on the entity edit form, which can be rearranged on the "Manage fields" screen for this bundle.
- provide display elements on entity view modes, which can be rearranged on the "Manage display" screen for this bundle.
- do something if the entity is saved, created, deleted, etc.
The cool thing is, the same behavior class can be reused for different entity types.
E.g. there could be a "BundleBehavior\\UrlAlias", which can be attached to taxonomy terms and to nodes, as long as the "EntityBehavior\\UrlAlias" is attached to both nodes and taxonomy terms.
Also, more than one instance of the same behavior could be added to a bundle.
So far this is all code, no configuration via UI.
Any UI configuration stuff either needs to be provided by the module itself, or preferably use the "bundle option".
Modules, and entity behaviors, can register "bundle options" to an entity type. Bundle options
- provide form elements on the bundle configuration form
- provide a storage for those bundle options.
- can attach behaviors to those bundles, based on the stored option values.
Yes, this proposal is still a bit vague, and a lot needs to be ironed out.
However, I think it is generally a reasonable direction to take.
One design considerations:
I intentionally want to split the behavior from its configuration UI. This allows to attach multiple behavior objects and maybe some other stuff, based on only one configuration checkbox. Also, this split will help to keep classes smaller.