@just_like_good_vibes
* I added functions which can be overwritten by sub classes. Not sure if it is too much. But now it is easy to change the title, description in sub classes.
* I also prefer container but we should do this in the big UI refactor update.
It's not so easy to access the entity inside layout forms. This should work now in every case.
* I removed the title from the fieldset
* Sort the field.
* Remove the field from the list
Christian.wiedemann → made their first commit to this issue’s fork.
After the Form refactor it should be easy to extend parts of the component form. Lets close it for now.
In discussion with Pierre we decided move to beta2 with a refactored ui
Or ui_patterns_component_definition. For me component_info is altering the plugin not the plugin definition.
I think it is already very easy to alter the existing form because we split it already in several subcomponents. So we can easily alter the subcomponent like ComponentSlotForm.
We can improve:
- add ComponentSlotItemForm
- Not remove UiPatternsOperations and maybe rename it to ComponentOperations
We need #title in each source. Otherwise the validation won't work. See
https://www.drupal.org/project/ui_patterns/issues/3461277
📌
Sources don't support required - #title missing
Active
.
I think we should move this to beta2 and redesign the ui in general.
Christian.wiedemann → created an issue.
Christian.wiedemann → created an issue.
Christian.wiedemann → created an issue.
1. This is done wrong in Block Source which we propably remove.
2. I am not sure about that. Actually I think it is good to have allways the same key in every consumer. We may provide a getConfigurationKey() function to overwrite that? Should we? @pdureau @Grimreaper
3. Should we provide an own trait for that? I would vote for that- @pdureau @Grimreaper
I used component_definition_alter instead of component_info for the hook name. Thought it is more straight forward.
This should work if
{{ region_attributes.REGION }}
are printed.
Christian.wiedemann → made their first commit to this issue’s fork.
@just_like_good_vibes thanks! I fixed your remarks.
Please merge this first. I changed a lot of code. (I also updated the t( to $this->t())
Was a lot more than I think, but now is everything clean. (I hope)
Christian.wiedemann → made their first commit to this issue’s fork.
YEAH it is merged. Thanks, thanks, thanks!!!
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?
(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.