Chain prop sources

Not sure if we should do this in UI Patterns. I think it is not a problem to create a new Source which selects multiple subsources. But maybe we should do it in ui_patterns_settings?

Currently the only case I see is for attributes props.

So a new source for attributes which would allow to instanciate as many other attributes sources as desired.

As there is no external dependency, I think it can be provided by UI Patterns directly.

There are multiple nice usecases.

for example, to invert a boolean value, to filter an output, to trim a string... etc etc

we should also think about the storage.
for a given source attached to a prop or to a slot delta, we have "source_id" and "source".
if we introduce a native mechanism to chain, we should think about how it would/cloud be stored.

There are multiple nice usecases.
for example, to invert a boolean value, to filter an output, to trim a string... etc etc

Indeed, and we need to scope this. I would like to introduce a restriction to avoid rewriting a full data processing framework inside UI Patterns 2 and maange unexpected side effects: we transform from the same prop type to the same prop type.

So:

• from attributes to attributes: any attribute source can be a filter, the attribuets are merged at each steps with something like AttributeHelper::AmergeCollections
• from string to string: trim, upper, replace...
• from boolean to boolean: invert...

Is it a new plugin type? I was initially kind of investigate TypedDataFilter plugins from https://www.drupal.org/project/typed_data →
What else can we study from Drupal contrib?

A new plugin type yes, we already talked about it, and that seems to be clearly a new plugin type.
maybe we would need it also for conversion from one prop type to another.
In other words, we could also renovates our conversion mechanism which is now very simple and not easily alterable...

so let me rephrase :
- a new plugin type to apply an operation from one prop type to the same prop type. those plugins may be used in components prop forms and component slot forms. One would select a source first, and one would optionally add a sequence of those plugins.
- a new plugin type to declare a conversion from one prop type to another. the introduction of those plugins would be done with a renovation of the prop type conversion system (declaration and conversion paths computation)

we could also renovates our conversion mechanism which is now very simple and not easily alterable...

Wow! That sounds very interesting.

- a new plugin type to apply an operation from one prop type to the same prop type. those plugins may be used in components prop forms and component slot forms. One would select a source first, and one would optionally add a sequence of those plugins.
- a new plugin type to declare a conversion from one prop type to another. the introduction of those plugins would be done with a renovation of the prop type conversion system (declaration and conversion paths computation)

I agree only the first kind must be available in the admin UI, but I guess it can be a single plugin type because:

• they share the same interface
• we will also need the first kind in the revamped prop type conversion system

yes, only the plugins acting on a single prop type are available in the UI.
the conversion plugins are internal only.

guys, i will take that one.
After discussing with Christian, i think we may have something nice