SdcPropToFieldTypePropMatcher was developed in https://git.drupalcode.org/project/experience_builder/-/tree/research__d... and was merged into 0.x as one of the starting points.
It proved matching SDC's prop's JSON schema shapes against Field Type's props + validation constraints was possible. But it didn't implement everything.
static prop sources (see 3.1.2.b in docs) — see \Drupal\Tests\experience_builder\Kernel\PropShapeRepositoryTest::getExpectedStorablePropShapes() for the supported onesdynamic prop sources (see 3.1.2.a in docs)DynamicPropSource) using the Choice constraint? Note that \Drupal\experience_builder\SdcPropJsonSchemaType::toDataTypeShapeRequirements() already does this:…
SdcPropJsonSchemaType::STRING => match (TRUE) {
array_key_exists('enum', $schema) => new DataTypeShapeRequirement('Choice', [
'choices' => $schema['enum'],
], NULL),
…
→ what's missing is that the list_string field type does not yet generate the appropriate validation constraints! Even though It does implement \Drupal\options\Plugin\Field\FieldType\ListItemBase::getPossibleValues(), which is supported not by the Choice constraint, but by the AllowedValues constraint, which is almost the same. So perhaps the code above should be updated to match against that constraint instead?
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | adapter-mapping.png | 71.92 KB | lauriii |
Show commandsStart 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:
changes, plain diff MR !73
Comments
Comment #2
tedbowLooking into this
Comment #4
tedbowWe should fix #3458580: Document in great detail where constraints for data leafs is authoritatively defined first
Comment #5
wim leersSee #3458580-5: Document in great detail where constraints for data leafs is authoritatively defined — that's in, but it might still be insufficient. I was unable to tell based on that issue summary + this issue.
Comment #6
wim leers@tedbow is not actually working on this, but on #3456024: Lift most logic out of ComponentTreeItem::preSave() and into a new validation constraint.
Comment #7
wim leersActually, I think this would no longer be in the critical path once we do #3461499: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings along with predefining the needed
PropShapeInputs for someenum-using SDCs.Demoting priority.
Comment #8
wim leersI don't think it is likely that a
{type: string, enum: …}SDC prop schema would be able to be supported by existing structured data (i.e. existing entity fields). IOW: aDynamicPropSourcefor them seems to be a rather edge case need.But I do think it's a hard requirement that SDCs with such props are supported, so supporting
StaticPropSources for them is crucial.In working on #3461499: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings, I realized that the "matching" infrastructure makes more sense for
DynamicPropSource, but far less so forStaticPropSource. And in fact … I've got exactly this use case working there: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...Comment #9
lauriiiThis is indeed a scenario which doesn't work very well with the current
DynamicPropSourceconcept because mapping enum values 1:1 introduces tight coupling between the data model and the components. I'm glad we're getting to the weeds because it helps us discover these scenarios.For this scenario, we'd need some concept of mapping values. I'm wondering if it would make sense to implement this as an adapter:
Comment #10
wim leersThat's what adapters are indeed for.
Comment #11
lauriiiThank you for confirming that @Wim Leers! I was worried that this would be challenging from technical perspective, and felt more confident about designing a UX for this. I would not say that it's a trivial UX task but it should not be insurmountable. I think that's a good sign given that we both feel good about this *high-five* 😊
Comment #12
wim leersThis is not for #3454094: Milestone 0.1.0: Experience Builder Demo, so marking for a later phase.
More context: #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings.
Comment #13
wim leersNow that #3450496: Clarify the "shape matching" bits: namespaces, `CODEOWNERS` and as issue queue component landed, the remaining work here became clearer:
static prop sources(see 3.1.2.b in docs) — see\Drupal\Tests\experience_builder\Kernel\PropShapeRepositoryTest::getExpectedStorablePropShapes()for the supported onesdynamic prop sources(see 3.1.2.a in docs)Comment #15
wim leersBecause >50% of the https://git.drupalcode.org/project/experience_builder/-/merge_requests/73 MR won't be relevant anymore when #13 gets worked on eventually, I closed it.
3 tiny bits will still be relevant:
Now that I've explicitly linked those bits, it's definitely justified to have that MR closed.
Comment #16
wim leersComment #17
wim leersIMHO this not realistic nor feasible. #3512854: Determine core bug(s) and missing metadata that explain unmatched field type properties; make the reported % reflect reality documented why, in this commit. 👍