- Issue created by @larowlan
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
@niharika.s: wow, so nice to see this almost done! π€©
@larowlan:
I was expecting each plugin to be able to define it's own settings and hence SDC and block components could retain plugin_id, whilst JS components could use something else.
The problem with that is that that won't work with:
id: # This ID intentionally does not use `type: machine_name`, because it is a composite ID that is better validated # using the `StringParts` constraint than the `RegEx` constraint. type: string label: 'Component' constraints: StringParts: separator: . reservedCharacters: - ':' reservedCharactersSubstitute: . parts: - '%parent.source' - '%parent.settings.plugin_id'
This guarantees consistent, meaningful
Component
config entity IDs.See that last line there: that's immutable. There's no other way I know of in config schema to achieve this.
I think
label: 'Block component settings' mapping: local_source_id: label: 'Block plugin ID' constraints: PluginExists: manager: plugin.manager.block interface: Drupal\Core\Block\BlockPluginInterface
is plenty clear: for every
Block
-sourcedComponent
config entity, thelocal_source_id
must be a block plugin ID. The validation constraint makes this firm.And the equivalent for a component source using config entitities:
label: 'Code component settings' mapping: local_source_id: label: 'JS Component ID' constraints: ConfigExists: prefix: experience_builder.js_component.