πŸ‡©πŸ‡ͺGermany @Christian.wiedemann

Account created on 14 July 2010, almost 14 years ago
#

Merge Requests

More

Recent comments

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

@just_like_good_vibes thanks! I fixed your remarks.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

Please merge this first. I changed a lot of code. (I also updated the t( to $this->t())

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

Was a lot more than I think, but now is everything clean. (I hope)

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

YEAH it is merged. Thanks, thanks, thanks!!!

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

Yes we are nearly done now.

I update the MR with comments.

Following ideas - but we can do that later:

* Should we introduce a "field" tag? I think we should only display field related sources.

protected function getSourcesTagFilter(): array {
return [
      "field" => TRUE,
      "widget:dismissible" => FALSE,
      "widget" => FALSE,
    ];
  }

* Should we also introduce tags also for the DerivableContextPluginBase annotation to filter contexts?

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

I already prepared that. I take the issue

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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?

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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).

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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!

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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'])

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

@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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

Christian.wiedemann β†’ changed the visibility of the branch 3421615-undefined-index-error to hidden.

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

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

Production build 0.69.0 2024