Discover cases where is no 1:1 map between field, prop and widget values

I opened ✨ [PP-1] Make link widget autocomplete work (for uri and uri-reference props) Postponed as a child issue.

AFAICT 📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active fixed this. Can you confirm? 🙏

I think there are a few more curly bits here:

• Element validate callbacks - e.g entity autocomplete elements change the value set on a field in a validation callback - we have no way to do this yet without submitting the Drupal form structure via the form submitter - 📌 Support server side massage and validation of component prop form values Active is probably where we'd handle that
• Value callbacks - e.g. date time element takes the incoming values and converts them into something else - I think transforms have resolved this, but we need to confirm - like in 📌 Support server side massage and validation of component prop form values Active as well
• Things where the shape of what we store is different to the resolved props in the model and we can't resolve them client-side - e.g. media references - we store target_id but resolve to src/alt/width/height - 📌 Support server side massage and validation of component prop form values Active , 📌 Split model values into resolved and raw Active and 📌 Maintain a per-component set of prop expressions/sources Active will hopefully resolve that

So it would be good to keep this open in the meantime, but postponed on those.

🤩 Clearly you've got a deep handle on this problem space, and I'm very grateful for that! 😊🙏

📌 Support server side massage and validation of component prop form values Active and 📌 Maintain a per-component set of prop expressions/sources Active landed, which means this is now only blocked on 📌 Split model values into resolved and raw Active

This ties into 📌 Provide visibility into which (core) field type props can be mapped into Content Type Templates vs not Active : the \Drupal\Tests\experience_builder\Kernel\EcosystemSupport\FieldWidgetSupportTest that that introduced should be expanded here.

Since #3512433-6: Provide visibility into which (core) field types (74%), field type props (63%) can be mapped into Content Type Templates vs not, and which field widgets (36%) are supported → , FieldWidgetSupportTest can provide you with a precise list of which field widgets are not yet supported by XB (i.e. do not have the xb.transforms metadata on their plugin definition).

That makes it easier to build an overview of what the remaining work is. Especially because this issue should discover all cases, including for field types that XB does not support yet. That information is surfaced in FieldTypeSupportTest.

We want @larowlan to start tackling this this sprint, which is why 📌 Split model values into resolved and raw Active is also in the sprint.

Repurposing this as a parent meta for tracking widget support.

Adding 📌 Multiple fields widget should fully work in the contexual form Active , 📌 Get Options as buttons in Page Data form working Active as additional children

Fixing link

All child issues specifically are scoped to making these widgets work in the (aka content entity) form.

That means they're relying on core's existing entity form submission logic, not #3499554's xb.transforms that powers the live updates of the component instance form (ComponentInputsForm), nor #3499550.

IOW: this relies on the following code path:

1. client gathers all values of all inputs in the content entity form in the tab
2. passes it to server via the entity_form_fields, contains values like title[0][value]=Hello
3. \Drupal\experience_builder\Controller\ApiLayoutController::post() receives entity_form_fields
4. entity_form_fields ends up in \Drupal\experience_builder\ClientDataToEntityConverter::setEntityFields()
5. ::setEntityFields() submits the actual entity form, which returns values like title[0][value]=Hello, for the client to receive

I was wrong in #12

This means my comment in #12 was wrong! Back then I thought that field widgets in both the content entity form and the component instance form use client-side transforms. Since then, I learned that field widgets on the content entity form don't use client-side transforms.

That means

This issue needs to:

1. identify the full list of core field widgets that have such a non-simple (not 1:1) mapping
2. articulate a strategy to surface these automatically, preferably by expanding the test coverage in \Drupal\Tests\experience_builder\Kernel\EcosystemSupport\FieldWidgetSupportTest if possible, and otherwise by introducing new test coverage.

is inaccurate.

FieldWidgetSupportTest ⇒ (simple and complex) widgets work in ComponentInputsForm using client-side transforms

FieldWidgetSupportTest is testing the presence client-side transforms on field widget definitions, and assumes that any field widget only gets its client-side transforms defined if and only if there's an explicit end-to-end test for it in prop-types.cy.js.

That is why in 📌 Get Options as buttons in Page Data form working Active , @bnjmnm explicitly removed the client-side transform for the options_buttons widget, because that was not actually being tested!

entity-form-field-types-test.cy.js ⇒ (complex) widgets work in (content entity) form

Instead, that issue and all other child issues are AFAICT intended to prove that a certain field type + widget works in the form by expanding the new ui/tests/e2e/entity-form-field-types-test.cy.js end-to-end test.

AFAICT there's no way to do a unit or kernel test that reasonably achieves the same level of confidence: we need that end-to-end test for the form! But we do NOT need it for the case where there's a simple 1:1 mapping between field, prop and widget values.

Please confirm 🙏

1. Updated the issue summary and title based on my understanding. Please confirm 🙏
2. If that was correct, then AFAICT the sibling issue for this is 📌 [PP-2] Redux sync on ALL prop types, not just ones with a single [value] property Postponed . that can't be completed until 🌱 [META] Expand support to *all* SDC prop shapes, and *all* Active adds the necessary shape matching (SDC prop → field type + widget) to make all widgets appear in the all-props component instance form. Please confirm 🙏

Yes, all of that is correct @wim leers - thanks!

There's also one final task after the two sibling issues are completed - which is from a comment @effulgentsia made on the media library issue - ideally when there is no client transform for a widget that is used in a component inputs form we can fall back to server side manipulation rather than throwing a logic exception like we currently do. There is at least one widget in use in the all props component (Date range) that currently has no transform - but we can add a transform for that. We can add a new test-only widget for testing the server side version.

Unassigning the meta

#19: for that I created 📌 Implement automatic fallback to server-side widget value transforms in "page data" (content entity form) Active 🤓

New children

Updating children

AFAICT the issue title and summary are no longer accurate: — but that's not true for 📌 Add e2e tests for uri widget in page data form Active , 📌 Add e2e tests for textfield widget in page data form Active and some others.

In other words: hasn't this simply evolved to cover all core field widgets? 😅 (Which would not be a bad thing IMHO!)

Agree, done
Added a reference to multiple cardinality too, because adding the test for 📌 Add e2e tests for multi-value textfield widget in page data form Active has revealed a fatal error from the backend for multi-value widgets.

Trigger summary update.

8 of 22 remain, or 36%. Getting there! 🥳