Problem/Motivation
Let’s build a new form where:
- For both slots and props, we list them first and pick source for each of them
- We allow multiple source for slots but not for props
There are 4 form parts:
- Component selector
- Variants selector
- Slots
- Props
“Variants selector”, “Slots” and “Props” change according to the value of "Component selector”.
Form parts are “à la carte”, some “consumers” need only some parts.
Proposed resolution
See specifications: https://docs.google.com/document/d/1-GaMK1Qk-h0hmB7GtAcnqPTuCOGMaxeRguop...
Issue fork ui_patterns-3395953
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
pdureau commentedForm implementation too heavy
The form implementation was done using UI elements from paragraphs module, as it was initially discussed, but we underestimated the hevainess of the paragraphs source code.
Now 20 % of the project PHP code is found in /src/form/
Also, addition of:
The current state of specifications is taking inspiration from Image Styles admin pages and Manage Display admin pages. It may be lighter because using Drupal Core native form elements.
Update of the slots & props forms when variant is changes
This is an undocumented behaviour. I know we want to make the condition mechanism addable in UI Patterns Settings 3.x, but is there a simpler way ? Also, if we change variants, do we keep our props settings?
Context management
How to add context to Source plugins was documented and tessted. But it still not clear how to set the conetxt from the consumer plugins (layout, field formatters...).
Maybe it is not implemented yet in the form builder:
Failed tests
I don't know if the issue is on the "consumer" side or the form builder side:
Layout plugin:
Block plugin:
View style plugin
FieldFormatters:
alterComponent
Some source plugins have alterComponent() method which is a successor of UI Patterns Settings alterElement() method.
Examples:
Do we manage them in the form builder, because we already buildComponentData() here? Or do we move this and buildComponentData() to another service?
Comment #9
pdureau commentedComment #10
pdureau commented"Form implementation too heavy" will be done in #3414363: [2.0.0-alpha1] Form builder: Simpler sources selector (1/2)
Comment #11
pdureau commented"alterComponent" was already done in the ComponentElementBuilder
Comment #19
pdureau commentedMerged. Future tasks will be done in dedicated issues.
Comment #22
christian.wiedemann commented