Problem/Motivation
Just had the need to implement form with conditions (from Condition Plugins) for two different module settings pages.
I think conditions for settings forms or entity forms aren't a rare case and most of us have seen them already (or someone implementing the conditions by hand, as they weren't aware it exists or how to use them - indeed it's not easy to find documentation, but that's another topic).
Typical forms where such conditions are used:
- Core Blocks
- Tracking / analytics integration modules to control visibility of the hook_page_attachments() added libraries (there are many and most of them implement the conditions not using Condition Plugins!)
- Context module
- Asset injector module
- ...
Looking for existing implementations of form using conditions, I found
https://git.drupalcode.org/project/core_extend/-/blob/8.x-1.x/src/Form/C...
in the old https://www.drupal.org/project/core_extend module.
And I think that's an excellent basic idea for core to unify and simplify use of conditions in forms!
So the question is, if a trait is the best way to provide an easier integration (I think so) or if a form element would even make sense. Thinking about that, I think a form element would be hard to configure, harder to individualize and as conditions are typically displayed as vertical tabs, I think a form element would be untypical.
Another thing I found in my investigations was, that most contrib modules implementing Conditions in forms, were copying the implementation from BlockForm, for example see lazyloader module:
https://git.drupalcode.org/project/lazyloader/-/blob/8.x-1.x/src/Form/Ad...
Maybe the trait could help to reduce boilerplate code copies?
Steps to reproduce
Implement a Condition Plugin form in core or contrib
Proposed resolution
Add a ConditionsFormTrait or a "conditions" form element to core
Remaining tasks
- Discuss
- Implement
- Test
- Release
User interface changes
None
Comments
Comment #2
anybodyFeedback welcome, before starting any kind of implementation, we should have green light from the core maintainers!
Comment #3
anybodyComment #4
anybodyComment #5
anybodyComment #6
owenbush commentedIn a similar vein to this, I created a number of different modules that make use of conditions in various ways:
Field Visibility Conditions
Layout Builder Styles Conditions
Views Access Conditions
All do similar things with Conditions - adding forms to third party settings, or exposing additional plugins for example, and I found I was recreating the wheel quite a lot.
I ended up just writing my own module with base forms and services necessary to build the forms and evaluate the conditions in various places. All three of those modules were retrofitted to use the helper module. Conditions Helper
Comment #7
penyaskitoTagging as we don't have a component.
Kinda related I just created #3527023: Conditions should have a flag for ANY/ALL
Comment #8
grevil commentedDuplicate of #3506721: Provide a "ConditionsFormTrait", which builds a generic conditions form.