Introduce a `Pattern` config entity

Discussed with @longwave, we agreed that this would make sense for him to tackle after 📌 Introduce an XB `PageTemplate` config entity Active lands, because it adds the validation constraint that will make this trivial to implement.

📌 Introduce an XB `PageTemplate` config entity Active is in.

📌 HTTP API to read+write PageTemplate and Pattern config entities Active is also already green, and is written in a sufficiently generic way that this should also just work!

This is actionable now. There's plenty of examples/blueprints to follow from #3478537.

Unassigning @longwave, who is on vacation right now :)

📌 HTTP API to read+write PageTemplate and Pattern config entities Active is in!

This should also expand the test coverage that #3479982 introduced for: this MR should add a testPattern() method as a sibling to XbConfigEntityHttpApiTest::testPageTemplate().

I know this isn't MVP, but will it be possible to validate above the component tree level?

I've repeatedly seen content management tools fail to recognize that both content and context validation are real needs, and if you're validating the meta relationships between components it makes sense to be able to query the component models as well.

Some example criteria a marketing approver might use:

1. A page can display more than one location component, but not if they have the same entity reference.
2. A page may have a carousel or a left column, but not both
3. A page must reference the title at least 4 times for SEO
4. All metadata keywords must be present in page content

@be-a-helper This seems outside the scope of this issue. Could you file a new issue for that question?

Few interesting edge cases that came up in the design process:

1. User should be able to undo adding or “deleting” a section from the library (I.e. CMD+Z)
2. User should be able to undo inserting a section (I.e. CMD+Z)

I'm wondering if this has implications on the data model?

#10:

will it be possible to validate above the component tree level?

Yes. See 📌 Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate Active for an example of the precision of validation that is already present :)

It'd be trivial to add more validation constraints — either for the XB module itself or for contrib/custom modules.

The 4 examples you cite would all be possible to implement. But the real challenge will be in which level to apply such validation constraints to: individual content entities (so at the XB field type level: \Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem) or at the content entity type bundle level (not yet implemented, stretch goal for 0.2.0 — see 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active , requirement 9, which is a stretch goal.

Agreed with @lauriii in #11 that #10 is out of scope for this issue. A new issue for your described use cases would be very much appreciated, but should be postponed on 🌱 [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model Active .

f.mazeikis → made their first commit to this issue’s fork.

Nice to see this getting started, @f.mazeikis — did a very high-level initial review pass 🤓

🏓 Reviewed again.

This time in slightly more detail.

Now that 📌 [PP-1] Add support for Blocks as Components Active is in, we can properly push this forward 👍

FYI, the validation pieces I mentioned above are blocked on 📌 `ComponentTreeMeetRequirements` constraint validator must be updated now that Blocks-as-Components are supported Active . 😅

📌 `ComponentTreeMeetRequirements` constraint validator must be updated now that Blocks-as-Components are supported Active is in! This is now properly unblocked 👍

Down to 2 non-commit blocking nits that would be nice to see resolved prior to merging, but I've already approved the MR — thanks @f.mazeikis! 😊