Problem/Motivation
While helping on #3542273: Remove EntityViewDisplay::getDisplayInfos , I have noticed our Entity View integration is maybe a bit too complicated:
- Some logic has not been moved out
DisplayBuilderEntityDisplayInterfaceimplementations when we did #3549266: Move DisplayBuildableInterface to a new plugin type - Some logic is duplicated or redundant
- The parts specific about Layout Builder will not be easy to extract if we do #3545596: Move Layout builder support to external module
Proposed resolution
TODO:
- Remove duplicated
DisplayBuilderEntityDisplayInterface::getDisplayBuilderOverrideField()implementations - Merge
DisplayBuilderOverridableInterfaceintoDisplayBuilderEntityDisplayInterface; because there are always implemented together - Replace
<code>EntityViewDisplay::getDisplayInfos()byEntityViewOverride::getDisplayInfos()
Then, let's move import logic from DisplayBuilderEntityDisplayInterface::initialImport() to buildable plugin. It doesn't make sense anymore to have the logic split in 2 different place. Buildable plugin have already everything they need to carry those tasks.
This will also allow to split "Import from Layout Builder or Manage Display configuration." into:
- Import from Layout Builder configuration.
- Import from Manage Display configuration.
Issue fork display_builder-3593247
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 commentedComment #4
pdureau commentedit looks good so far...
Comment #5
pdureau commentedAlso tested locally, by clicking around in UI, and doing all kind of imports from Manage Display and Layout Builder.
Comment #6
pdureau commentedAs a follow-up, we may be avle to totally remove the
EntityViewDisplayVSLayoutBuilderEntityViewDisplaysplit (and hopefully theEntityViewDisplayFormVSLayoutBuilderEntityViewDisplayFormsplit).We keep 2 different 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\EntityViewDisplayEditFormCan we promote composition over inheritance?
EntityViewDisplayTraitEntityInterface::preSave()which could be replaced byhook_entity_presavewith conditionsEntityInterface::postSave()???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_viewDisplayBuilderEntityDisplayInterface::isDisplayBuilderEnabled()to move to buildable pluginDisplayBuilderEntityDisplayInterface::getDisplayBuilderOverrideField()to move to buildable pluginDisplayBuilderEntityDisplayInterface::getDisplayBuilderOverrideProfile()to move to buildable pluginDisplayBuilderEntityDisplayInterface::isDisplayBuilderOverridable()to move to buildable pluginWe already implements
hook_entity_delete, we can gather all hook implementations which is altering Entity View Display entity type into a single class which will look very similar to the currentEntityViewDisplayTrait. Like an "entity type decorator"For forms:
EntityViewDisplayFormTraitentiity_form_alterhook.EntityViewDisplayFormTraitonly overridesFormInterface::submitForm()I will create the ticket once this one is merged.
Comment #8
mogtofu33 commentedComment #10
pdureau commentedThanks. Follow-up #3594228: Remove explicit references to Layout Builder