🇩🇪Germany @Christian.wiedemann

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

I fixed the meta:enums.

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

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.

So now the MR is smaller.
I renamed the group stuff to Picker.
Each picker has two mehtod to decide which sub source are displayed.
I also removed the field property picker.

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.

Merged! and Cool!

I already prepared that. I take the issue

This can easily done with the refactoring of the forms. We can use slot form widget inside a block and we are done. Should I take it?

Hopefully the last refactor of the component form element.

Following stuff improved:
- Add Slot and Prop Component to render a single slot or prop for a given component.
- Add consistent documentation
- Clean argument mess inside the functions. Every function: ($element, $form_state, $definition, ?$wrapper_id)
Each methods takes sources_context etc. from the element array.
- Streamline ajax handling. No counting etc. You can put every component class in any form and ajax works.

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

Rebased against the current dev. Filter mechanism works great. I am using tags also to filter for groups. Flor that I add the mech to compoent form element.
I think we should move the Field Sources to ui_patterns not to ui_patterns_field_formatter. Field formatter is only the formatter.

Ok merged.

But lets merge. It would be easy to refactor that later.

Short talk to finalize this. Than we I can rebase my stuff today and also provide the MR for the attribute stuff.

Hi Piere, both functions are factory functions which are usually not covered by an interface.

So for me
1. RequirementsContextDefinition and RequirementsContext is fine without an interface. I like your proposal of an ?additional? factory method forRequirements(array $requirements = [], ?string $label = NULL) or forRequirements(array $requirements = [], ?string $label = NULL) .
2. SourcePluginBase::addRequirementsToContext(array $context, array $values): array; could we maybe move also to the
RequirementsContext class. I "think" factory should belong to the class which is created.
RequirementsContext::attach(RequirementsContext::forRequirements(['field_property']), $contexts).

Sorry for the late answer. I was also fine with the solution before. But I think it is better now in sense of more clear. Let's merge!

I checked that yesterday. It can be done via rector. I prepared the attributes classes and the rector config yesterday.

You are a machine. Looks great and brutal fast. :)
Just one thing:
SourcePluginBase::addContextRequirementsValues is not clear for me. Why is the first argument contexts and not only the context which needs the "RequirementsValues". Maybe we create an own Context Class like "Drupal\Core\Plugin\Context\EntityContext"
and Add a static Method $context = RequirementsValuesContext::create('key', ['value1']) and RequirementsValuesContext::attach($context, ['value1'])

I am thinking about your comment:

"Instead of introducing a protected ::getConvertibleDefinitions() method and putting the logic into the public ::getDefinitionsForPropType() method:"

I think it is not a good idea to handle the logic inside the caller. Lets discuss that during our next meeting

G4MBINI → credited Christian.wiedemann → .

Grimreaper → credited Christian.wiedemann → .

The new version will only be for drupal 10.2 or above

Thanks to all!

Thanks to all!

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

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

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

Christian.wiedemann → changed the visibility of the branch 3444711-2.0.0-alpha3-layouts-contextual to hidden.

@oleb Sorry I recordnized to late that the issue is assigned to you. I know the problem from UI Patterns Layout Builder so I did the fix. It is just one line inside the build method. Please use the 2.0.x to review.

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

Hi, I updated the types and the docs.

This feature does two things:

1. Provide values from a component as options into a field. This is done by updating the field storage with an allowed_values function which points to the component. So one field storage maps to a component setting
2. Proprocess the value of this field into the component if the field exists inside the entity.

The problem with the current implemention is that:
1. There is a hard link between a field storage and a component setting
2. Every viewmode takes this mapping

So actually this are two features.
1. Provide values to a field
2. A SourcePlugin where you can easily set field value to a property. Something like EntityValueSourcePlugin.

For part 1 I have no idea. For part 2. we should discuss if we need it and if we can reuse code from field formatter to handle every property of every value.

The variable is only available for Nodes. Right now I don't see any usecase to set the node to preview mode. I think we can remove it safely.

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

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

I think we can move the code from alterDefinitions to alterDefinition and remove alterDefinitions.

Thanks!

Thanks

Christian.wiedemann → created an issue.

pdureau → credited Christian.wiedemann → .

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

Christian.wiedemann → created an issue.

Thanks!

Thanks!

Christian.wiedemann → created an issue.

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

Christian.wiedemann → changed the visibility of the branch 3421615-undefined-index-error to hidden.

Christian.wiedemann → created an issue.

pdureau → credited Christian.wiedemann → .

Christian.wiedemann → created an issue.

Christian.wiedemann → created an issue.

Christian.wiedemann → created an issue.

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

pdureau → credited Christian.wiedemann → .

This is also fixed

Thanks all!

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

G4MBINI → credited Christian.wiedemann → .

pdureau → credited Christian.wiedemann → .

Thanks!

Thanks. Yes it should.

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

Thanks!

pdureau → credited Christian.wiedemann → .

pdureau → credited Christian.wiedemann → .

oui, aucun problème

yes aucun problème

Totaly fine with the implementation. It can be merged.

Grimreaper → credited Christian.wiedemann → .

Grimreaper → credited Christian.wiedemann → .