[2.0.0-alpha3] Add allow_variant_expose source plugin

Christian.wiedemann → made their first commit to this issue’s fork.

I created a variant prop type inside the componentManager and use this prop inside the form builder under the variant_id key. Maybe we simple use it as the first property and remove it as a special form element.

hello,
i am just getting the code, and i get the following error: please review.

Uncaught PHP Exception TypeError: "Drupal\ui_patterns\Element\ComponentPropForm::getSources(): Argument #2 ($definition) must be of type array, null given, called in /var/www/html/ui_patterns/src/Element/ComponentPropForm.php on line 75" at /var/www/html/ui_patterns/src/Element/ComponentPropForm.php line 167

Hi,
I thought about this topic. I think we are on the right way. I think the "still" the main problem is how we can "configure" a source. But this is out of scope of this issue. For that reason, we should not introduce the ui_patterns key in this issue. Because it is a hacky way to do configuration and if we don't want this we should not introduce a "hidden" workaround. (right now, maybe later).
Maybe UI Patterns Settings introduce this mechanism. So to make it simple we have 3 possibitlies:

1. Display only enums
2. Load the component via context. The component_id is a context.
3. Introduce a document configuration way. UIPatterns 1 uses getThirdPartyConfiguration for this.

I updated 3444822-2.0.0-alpha3-add-allowvariantexpose with the latest meta:enum stuff. Please review

hello, ok i check now

for the issue, i recopy my small comment from this morning:

there is a little mistake when you fill in meta:enum
in component plugin manager line 182.

the meta:enum expect the format :
variant_key: title1
variant_key2: variant_title2

where currently, what is provided is a copy of the content of the variant part in the component which is :
variant_key:
title: title1
variant_key2:
title: variant_title2

I fixed the meta:enums.

(But it worked with key: [tilte: title]) as well. Maybe meta:enums supports both?

Indeed, this is the expected structure:

"someProperty": {
    "type": "string",
    "enum": [
        "choice-1",
        "choice-2",
        "choice-3"
    ],
    "meta:enum": {
        "choice-1": "Description of Choice #1.",
        "choice-2": "Description of Choice #2.",
        "choice-3": "Description of Choice #3."
    }
}

https://github.com/coveooss/json-schema-for-humans/issues/227

hello, nice fix :)

but one small thing.
when variants exist, the selection of a value is not required.
it should be required right ?

i don't know yet how to do this nicely.
Pierre suggested to define a custom source compatible with variant prop type, instead of the select right now.
should we do it?
if yes, why not defining a VariantSelectorWidget, which would derive from SelectWidget, and we can then introduce some little logic...

what do you think?

if this is resolved, we can merge

when variants exist, the selection of a value is not required.
it should be required right ?

No, variants are always optional

ok so let's merge