[2.0.0-beta2] Number Enums which are mapped with SelectWidget

Looks like a DaisyUI yml definiton :)))

A friend told me this same issue on another project... But when I tested with UI Suite DaisyUI, I didn't have that problem ...

@g4mbini
I encountered the same issue. As a temporary solution, I had to change my enum values to strings (e.g., use '1' instead of 1). In general, it seems that Drupal select widgets always return strings, so the UI Patterns module should account for this. I'll take some time to reproduce the issue and work on it.

Let's be careful with this one.

• A new proptype adapter? It may be overkill
• In SelectWidget? the best place to do the change. It may be the select form element which is casting the integer value as a string
• in EnumPropType::normalize()? Look like a good place too, but the method is static and doesn't have access to the prop definition

So, what can we do in SelectWidget ? a #process callback?

Maybe we can leverage SourceInterface::getPropValue()

Proposal:

  public function getPropValue(): mixed {
    $value = $this->getSetting('value');
    $enum = $this->propDefinition['enum'];
    // Select form element is alwyas storing values as strings, but we want
    // a value with the same typing as the related enum value.
    return match (TRUE) {
      in_array($value, $enum, TRUE) => $value,
      in_array((int) $value, $enum, TRUE)  => (int) $value,
      in_array((float) $value, $enum, TRUE) => (float) $value,
      default => $value,
    };
  }

But we need that for all enums independent of the source. Why not move that logic to an proptype adapter for all enums of type integer

Because it is the source which is making a mess here.

What would be the prop type adapter you are thinking about?

Or a EnumSourceBase class with getOptions and and we overwrite the getValue method and we do the cast there.

I took the time to reproduce this with the latest updates in 2.0.x but couldn't reproduce the issue.
It seems everything is working as expected, so I believe we can close this issue with the status "cannot reproduce"
@christian.wiedemann, you may want to test again with the latest 2.0.x and feel free to reopen in case the problem persists

This is surprising, too goof to be to true :)

Let's check again.

So, the proposal:

• let's use SourceInterface::getPropValue() with the Pierre's proposal in #5
• but let's do it in a EnumSourceBase as proposed by Christian. SelectWidget is the only plugin extending EnumSourceBase for now