Problem/Motivation

As a follow-up of #3593247: Move some entity view logic to buildable plugins and an alternative to #3545596: Move Layout builder support to external module, can we to totally remove any explicit reference of Layout Builder in our code (except migration logic) more precisely:

  • the EntityViewDisplay VS LayoutBuilderEntityViewDisplay split
  • and hopefully the EntityViewDisplayForm VS LayoutBuilderEntityViewDisplayForm split

We are currently keeping those 2 classes with explicit reference to Layout Builder because of the classes we are extending from Core:

  • LayoutBuilderEntityViewDisplay is extending Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay instead of Drupal\Core\Entity\Entity\EntityViewDisplay
  • LayoutBuilderEntityViewDisplayForm is extending Drupal\layout_builder\Form\LayoutBuilderEntityViewDisplayForm instead of Drupal\field_ui\Form\EntityViewDisplayEditForm

Proposed resolution

Can we promote composition over inheritance?

  • EntityViewDisplay has already no logic of its own, just an empty shell for the EntityViewDisplayTrait
  • LayoutBuilderEntityViewDisplay is only implementing EntityInterface::preSave() which could be replaced by hook_entity_presave with conditions
  • EntityViewDisplayTrait is implementing/overriding:
    • EntityInterface::postSave() could be replaced by hook_entity_update as we already do for display_builder_views?
    • EntityInterface::delete() could be replaced by hook_entity_delete?
    • ConfigEntityInterface::calculateDependencies() and ConfigEntityInterface::onDependencyRemoval() may be addressable with #3540069: Evaluate ObjectWithPluginCollectionInterface
    • EntityViewDisplayInterface::buildMultiple() could be replaced by hook_entity_view or hook_entity_display_build_alter ?
    • DisplayBuilderEntityDisplayInterface::isDisplayBuilderEnabled() could be moved to EntityView buildable plugin
    • Other DisplayBuilderEntityDisplayInterface methods could be moved to move to EntityViewOverride buildable plugin

We can group all hook implementations which is altering Entity View Display entity type into a single class which will look very similar to the current EntityViewDisplayTrait. Like an "entity type decorator"

For forms:

  • EntityViewDisplayForm has already no logic of its own, just an empty shell for the EntityViewDisplayFormTrait
  • DisplayBuildablePluginManager has just a little form alteration, which could be replaced by entiity_form_alter hook.
  • EntityViewDisplayFormTrait only overrides FormInterface::submitForm()
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

pdureau created an issue. See original summary.

pdureau’s picture

Issue summary: View changes

What about an entity storage handler extending ConfigEntityStorage instead of various hooks? May not be a good idea, just writing this down.

pdureau’s picture

Status: Active » Needs work

A MR has been created with some proof-of-concept work. It looks promising.

pdureau’s picture

EntityViewDisplayTrait nearly done, only remaining tasks:

  • EntityInterface::preSave() implementation in LayoutBuilderEntityViewDisplay has been replaced hook_entity_presave but not finished
  • ConfigEntityInterface::calculateDependencies() and ConfigEntityInterface::onDependencyRemoval() may be addressable with #3540069: Evaluate ObjectWithPluginCollectionInterface

Manual tests were done but just lightly. We need to do more before merging. phpunit and playwright are not enough for those specific mechanisms.

pdureau’s picture

Issue summary: View changes
pdureau’s picture

Feedback from Flroent (@grimreaper): no need to add the hook class in services.yml to have autowire.

Remove also the display_builder_views.services.yml entry