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
EntityViewDisplayVSLayoutBuilderEntityViewDisplaysplit - and hopefully the
EntityViewDisplayFormVSLayoutBuilderEntityViewDisplayFormsplit
We are currently keeping those 2 classes with explicit reference to Layout Builder because of the classes we are extending from Core:
LayoutBuilderEntityViewDisplayis extendingDrupal\layout_builder\Entity\LayoutBuilderEntityViewDisplayinstead ofDrupal\Core\Entity\Entity\EntityViewDisplayLayoutBuilderEntityViewDisplayFormis extendingDrupal\layout_builder\Form\LayoutBuilderEntityViewDisplayForminstead ofDrupal\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 byhook_entity_presavewith conditions - EntityViewDisplayTrait is implementing/overriding:
EntityInterface::postSave()could be replaced byhook_entity_updateas we already do fordisplay_builder_views?EntityInterface::delete()could be replaced byhook_entity_delete?ConfigEntityInterface::calculateDependencies()andConfigEntityInterface::onDependencyRemoval()may be addressable with #3540069: Evaluate ObjectWithPluginCollectionInterfaceEntityViewDisplayInterface::buildMultiple()could be replaced byhook_entity_vieworhook_entity_display_build_alter?DisplayBuilderEntityDisplayInterface::isDisplayBuilderEnabled()could be moved toEntityViewbuildable plugin- Other
DisplayBuilderEntityDisplayInterfacemethods could be moved to move toEntityViewOverridebuildable 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_alterhook. EntityViewDisplayFormTraitonly overridesFormInterface::submitForm()
Issue fork display_builder-3594228
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
Comment #2
pdureau commentedWhat about an entity storage handler extending
ConfigEntityStorageinstead of various hooks? May not be a good idea, just writing this down.Comment #4
pdureau commentedA MR has been created with some proof-of-concept work. It looks promising.
Comment #5
pdureau commentedEntityViewDisplayTrait nearly done, only remaining tasks:
EntityInterface::preSave()implementation in LayoutBuilderEntityViewDisplay has been replacedhook_entity_presavebut not finishedConfigEntityInterface::calculateDependencies()andConfigEntityInterface::onDependencyRemoval()may be addressable with #3540069: Evaluate ObjectWithPluginCollectionInterfaceManual tests were done but just lightly. We need to do more before merging. phpunit and playwright are not enough for those specific mechanisms.
Comment #6
pdureau commentedComment #7
pdureau commentedFeedback from Flroent (@grimreaper): no need to add the hook class in services.yml to have autowire.
Remove also the
display_builder_views.services.ymlentry