I think creating an individual class for this model transformer it's the common implementation (i.e. into core) and both will be easier to maintain. CallbackTransformer it's commonly used in tests to simplify.

👍

Done

This is an issue. The choice list is cached and reused. By doing this, you'll always get the same list when using the type multiple times (in a single form, nested forms or multiple forms) .

@HeahDude could probably give you more inputs than me for about this right now, because I think it was something he had to consider when working on #18334.
You should also avoid storing options in the form type's properties, as form types are instantiated once, it acts like a global state for the type and all its usages.

Right :) if we can solve it simply thats nice, otherwise lets leave it out. I can validate it additionally as well, yet it's nice to have.

Btw shouldnt this be self::getTimezones()?

Btw shouldnt this be self::getTimezones()?

Right :)

See #23652

You should also avoid storing options in the form type's properties, as form types are instantiated once, it acts like a global state for the type and all its usages.

An option could be return a new default choice loader instance instead of the current one return $this;? e.g.:

'choice_loader' => function (Options $options) {
    // ...

    return new CallbackChoiceLoader(function () use ($options) {
        return self::getTimezones($options['region']);
    });
},

But also, it involves remove the actual ChoiceLoaderInterface implementation and maybe I'm missing something...

@yceruto is right, we now need a dynamic TimezonesChoiceLoader implementation taking the option in its constructor.

@HeahDude what about the ChoiceLoaderInterface implem. Can we simply drop it?

Just moved I'd say ;).

It basically has not purpose anymore.. not sure we should preserve its api in any way (i.e. forward to the callback loader or so).

@yceruto is right, we now need a dynamic TimezonesChoiceLoader implementation taking the option in its constructor.

👍

Should be removed.

Missing dot.

"between a timezone identifier string and a DateTimeZone object"

I would add $regions = $options['regions'] and pass that only variable to the use statement.

1 === count($timezones) ? $timezones : reset($timezones)?

That would be weird.. :P

Ah yes sorry about that.

But we need an array all the time right? Why this change?

We get a flat array (1 region) or a nested one (multiple regions). Let me explain with a picture :)

It's just cosmetic sugar. IMHO.

Alright! Thanks for clarifying.

Missing dot.

Well.. it's consistent with the current format :)

Shall add the new options here as well 👍

right and not where I commented.

You should also document the new options here.

New options are just new features, so not required for any upgrade step. I tend to doc them in Form/CHANGELOG.

Something else is troubling me. With this new implementation can we still use this choice field as multiple? I guess we should handle an array of timezones too to be fully BC.

Good catch. Will look into that 👍

- throw new TransformationFailedException('Expected a known timezone identifier.');
+ throw new TransformationFailedException('Expected a known timezone identifier.', $e->getCode(), $e);

(same for every exception caught IMHO. Eventually, you don't even need to set a custom message, but just re-use $e->getMessage() 😄 . See DateIntervalToArrayTransformer for instance)

You could avoid duplicating this logic below by adding using a private method... or either by reusing a DateTimeZoneToStringTransformer without the $multiple flag.

Yeah.. wasnt sure :P resuing new self sounds nice.

I'm not sure we need this in the UPGRADE.md file. Unless there is a new code path to show.

The upgrade path is:

Before:
class MyTimezoneType extends TimezoneType
{
    public function loadChoices()
    {
        // override the method
    }
}

After:
class MyTimezoneType extends AbstractType
{
    public function. getParent()
    {
        return TimezoneType::class;
    }

    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefault('choice_loader', ...); // override the option instead)
    }
}

Removed ``ChoiceLoaderInterface`` implementation in ``TimezoneType``. Use the "choice_loader" option instead.

?

I like both. Let's do both? 😄

• Removed ChoiceLoaderInterface implementation in TimezoneType. Use the "choice_loader" option instead:

  Before:

  class MyTimezoneType extends TimezoneType
  {
      public function loadChoices()
      {
          // override the method
      }
  }

  After:

  class MyTimezoneType extends AbstractType
  {
      public function. getParent()
      {
          return TimezoneType::class;
      }
  
      public function configureOptions(OptionsResolver $resolver)
      {
          $resolver->setDefault('choice_loader', ...); // override the option instead)
      }
  }

+1 for Before/After code also ;)

After would be

class MyTimezoneType extends AbstractType implements ChoiceLoaderInterface
// ...
$resolver->setDefault('choice_loader', $this);

right?

Not necessarily. I think @HeahDude 's suggestion is enough to understand.

btw, while at it, is it worth to do this deprecation for other types? LanguageType and co. could do the same approach =/

It seems a way simpler implem. (CallbackChoiceLoader) compared to ArrayChoiceLoader.

An object is constructed at each iteration :/. What about:

$transformer = new self();

return array_map(function ($dateTimeZone) use ($transformer) {
    return $transformer->transform($dateTimeZone);
// ...

Minor simplification:

- $transformer = new self();

- return array_map(function ($dateTimeZone) use ($transformer) {
-     return $transformer->transform($dateTimeZone);
- }, $dateTimeZone);
+ return array_map(array(new self(), 'transform'), $dateTimeZone);

However, the actual is fine to me ;)

So update? Kinda like the one-liner :)

How about we name the option value DateTimeZone so people can use ['input' => \DateTimeZone::class]? This avoids typos and makes things more explicit as the value directly maps to a class.

I like this suggestion and we could also apply it for other Date*Type having this input option.
But I'd keep datetimezone as alias for consistency, as I'm not convinced deprecating old option values for other types would be worth it and such aliases are handful too (for configuration based form generation like in EasyAdmin for instance).

so.. strtolower? :)

strtolowering the whole FQCN won't help you much ;)

i meant if ('datetimezone' === strtolower($options['input'])) {..

then again im not sure using class-ish values for input makes sense (compared to data_class). It kinda implies it supports any class name, which it doesnt.