Overview
-
First there was the ability to store XB Component trees in content entities, in the XB field type (
- Then there was the ability to store XB Component trees in config, for the XB field type's default value (
type: experience_builder.component_tree). - Then a validation constraint was added that can consistently validate both of the above using the same logic:
ValidComponentTree, added in #3456024: Lift most logic out of ComponentTreeItem::preSave() and into a new validation constraint - Then a second, more detailed validation constraint
ComponentTreeStructurewas added for thetreeprop of a XB Component tree, in e #3460856: Create validation constraint for ComponentTreeStructure - Yesterday, a third validation constraint was added:
ComponentTreeMeetRequirements, used by the newPageTemplateconfig entity, because while both of the above validation constraints are also in use and are still relevant, some kinds of XB Component trees just do not make sense at the "page" level: they cannot useDynamicPropSources (because the host entity, could be different for each page aka route/controller — or even none!). Added in #3478537: Introduce an XB `PageTemplate` config entity
\Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem and its tree + props field props).
Proposed resolution
Use the new ComponentTreeMeetRequirements validation constraint on:
- ✅
the XB— done in #3478537: Introduce an XB `PageTemplate` config entity 👍PageTemplateconfig entity to disallowDynamicPropSource - the XB field type (
ComponentTreeItem), to disallowDynamicPropSource— because preliminary designs for7.1 Tokens(see #3455753: Milestone 0.2.0: Early preview) indicate that only the site builder will be able to link XB Component props toDynamicPropSources on the host entity type, aka use base/bundle fields' values. - 💁 #3479643: Introduce a `Pattern` config entity's issue summary with the sample config schema already uses this new constraint, just like the XB
PageTemplateconfig entity uses it 👍 - 💁 if/when #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model is worked on, the XB
ContentTypeTemplateconfig entity allow bothStaticPropSourceandDynamicPropSource
User interface changes
None.
Issue fork experience_builder-3481720
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 #3
wim leersI expect this to fail like so:
This has zero impact on the UI today, only on tests that need to be refactored a bit. @tedbow is best suited for that, because he worked on related validation constraints a few months ago and introduced
ComponentTreeTestTraitwhich will need to have its uses ofDynamicPropSources split out because many of those won’t be allowed anymore — as the cited test output failure shows.Comment #4
wim leersComment #6
tedbowAdded a comment in #3455629-33: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model because that issue will need to add back some of what is being remove here related to translation.
Comment #7
tedbowComment #8
wim leersComment #9
wim leersClearly I underestimated the complexity of landing this, because I'd completely forgotten about @tedbow's excellent
TranslationTestthat verifies the correct translation of the host entity's base/bundle field is being used! 🙈Thanks, @tedbow, for so gracefully pushing this across the finish line 🙏
As far as I'm concerned, this is RTBC. This still needs @tedbow's approval on the MR, so @tedbow: this is all yours to merge 😊
Comment #10
tedbowI think the MR needs @f.mazeikis' approval because of the changes to `/config/schema/`
Comment #11
f.mazeikis commentedLooks good, approved
Comment #13
tedbowComment #14
wim leersComment #15
wim leers🚀 This implemented point 2 of the proposed resolution. Point 1 already happened previously. Points 3 and 4 have their own respective issues 👍