Require content templates to have at least one dynamic property source

Created on 13 August 2025, about 1 month ago

Overview

Originally Content Templates were required have at least 1 dynamic prop source.

It was enforce by the schema

        ComponentTreeMeetRequirements:
          inputs:
            absence:
              - adapter
            # This tree MUST contain at least one dynamic prop source, or it's not much of a template;
            # it's just presenting static data.
            presence:
              - dynamic

but this meant that in many issues in 🌱 [META] Content templates Active were blocked by this requirement.
Because these were not done
📌 ComponentSourceInterface::inputToClientModel needs to support passing an entity Active
📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active

It also allowed
📌 Refactor ApiLayoutController into 2 sub-class to support Content Templates Active
Render template and support component operations in preview canvas Active
which were the first 2 issue creating the UI to be completed without solving all the dynamic link problem

Proposed resolution

Add back enforcement and the test coverage that was removed in 📌 Refactor ApiLayoutController into 2 sub-class to support Content Templates Active
There was test MR that shows just the changes that need to reversed https://git.drupalcode.org/project/experience_builder/-/merge_requests/1438

User interface changes

📌 Task
Status

Active

Version

1.0

Component

Page builder

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @tedbow
  • 🇺🇸United States tedbow Ithaca, NY, USA
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇫🇮Finland lauriii Finland

    I don't really see why this is something we would have to enforce. It's totally fine if users want to test static templates as content templates before they map props to a dynamic prop source.

  • Now that this issue is closed, please review the contribution record.

    As a contributor, attribute any organization helped you, or if you volunteered your own time.

    Maintainers, please credit people who helped resolve this issue.

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active landed a while ago.

    Lots of other statements in the issue summary are no longer true because many issues ended up going in a different direction based on design changes. Let's get the issue summary updated.

    EDIT: cross-posted

    I don't really see why this is something we would have to enforce. It's totally fine if users want to test static templates as content templates before they map props to a dynamic prop source.

    I strongly disagree.

    A ContentTemplate that is either empty or contains only StaticPropSources no longer is a template for presenting structured data. It's the equivalent of a spreadsheet where a formula (~content template) applied to different columns (~content entities aka structured data) all renders the exact same output, and ignores the inputs. In other words: it's nonsense.

    It's fine for me to be in such a state while working on it (IOW: auto-saves like this are fine, and allow you to preview it as such!), but it never makes sense to go live with such a ContentTemplate (IOW: validation constraint needed, which is checked when going from auto-saved to actually saved).

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇫🇮Finland lauriii Finland

    I don't see how this is a data integrity concern? This seems like a UX concern and us trying to babysit the users. I feel very strongly that we should not introduce validation of this type. It should be up to the user to decide what kind of template they want to create. Maybe all of the data is fetched using JSON:API or maybe you just want to preview how a static template would look like? This isn't really changing from what you can do today either because you can create an empty display mode today and that's fine.

Production build 0.71.5 2024