[2.0.0-alpha3] Implement PropTypeInterface::convertFrom()

Also in the scope of this issue: FormBuilder and/or ElementBuilder changes to process the method.

hello,
i added some code to handle the conversion and source selection.

Before merging:

• check linters
• remove boolean from String prop type
• remove slot from ViewLabel source

It is very good but there is something else I would like to ask.

Instead of introducing a protected ::getConvertibleDefinitions() method and putting the logic into the public ::getDefinitionsForPropType() method:

  public function getDefinitionsForPropType(string $prop_type_id, array $contexts = []): array {
    $definitions = $this->getDefinitionsForContexts($contexts);
    $definitions = array_filter($definitions, function ($definition) use ($prop_type_id) {
      return in_array($prop_type_id, $definition['prop_types']);
    });
    // Add convertible definitions.
    $convertible_sources_by_prop_id = $this->getConvertibleDefinitions($prop_type_id, $contexts);
    foreach ($convertible_sources_by_prop_id as $convertible_prop_id => $convertible_sources) {
      foreach ($convertible_sources as $source_id => $source) {
        $definitions[$source_id] = $source;
      }
    }
    return $definitions;
  }

I would prefer to keep those 2 methods independent from each others, and to call ::getConvertibleDefinitions() from the form builder.

Why?

If the source selectors are aware of each of which sources are "native" and which ones are coming from the "convert_from" mechanism, we can treat them differently. For example, by putting a separator between them, or by grouping them.

done, please review :)

should we tackle the following case :

a source X has declared prop type "integer".
in a string prop, we can select source X because conversion is possible between integer and string.

conversion from string to slot is also possible, but it is not declared from integer to slot.

in that latter case, do we explicitly try to find a conversions from integer to slot,
using a "conversion path" integer -> string -> slot
or we only cover direct conversions and require each conversion pairs to be declared and coded?

by the way, i just did a rebase of the current MR with branch 2.0.x, ready for review :)

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

thanks to issue 3454615 📌 [2.0.0-alpha3] Improved source plugins organization Fixed ,
we introduced tags to some basic ui_patterns sources.
The tags are used to filter sources fetched with method "SourcePluginManager::getDefinitionsForPropType" in the case of fetching sources with convertible to a specific prop type.
This allows to propose a better list of convertible sources for props and slots, especially string and slots.
The sources discarded from the convertible list, are the ones tagged with "widget:dismissible".
The sources tagged with "widget:dismissible" are widgets (in the sense the value is not automatically taken extracted from another data using drupal api), but the ones we think can be discarded when their prop type can be converted to the a target prop type.
For example, with string prop type, we have many simple prop types convertible to string : integer, urls .etc
To set value for a string prop using a source plugin, we don't want basic widgets for integer and urls to be available when we already have the textfield available which is natively compatible with string. "Path", "Url" & "Number" sources are discarded while textfield is kept in the list.
but the mechanism is generic :)

please review... i think now it may be ready for merge, addressing all previous comments except number #20 from Christian.

hello, freshly rebased MR

hello,
updated code, ready :)