Expose denormalizePropertyName/normalizePropertyName in a Trait

[VincentLanglet]

Description
While writing custom filters, I have the need for the denormalizePropertyName/normalizePropertyName method.
But currently to have them I have to extends AbstractFilter.

I feel like it would be more useful to have them directly in a trait in doctrine/common, and this trait could be used by both
ApiPlatform\Doctrine\Orm\Filter\AbstractFilter
ApiPlatform\Doctrine\Odm\Filter\AbstractFilter

I thought about adding them to PropertyHelperTrait but it requires adding a property nameConverter to this trait which means

• protected ?NameConverterInterface $nameConverter = null, needs to be changed in AbstractFilter to

public function __construct(
        ...
        ?NameConverterInterface $nameConverter = null,
    ) {
        $this->nameConverter = $nameConverter;
    }

and therefore doctrine/orm & odm package 4.2.9 won't work with 4.2.10 version of doctrine/common ; not sure if it's ok to make such change and add such requirement/conflict between packages

• If someone use the PropertyHelperTrait AND has a property nameConverter it will break

The other option would be to introduce a new Trait, but I'm not sure what would be a good name for it, based on the fact the first trait is pretty generic with PropertyHelperTrait... any suggestion @soyuka ?

[soyuka]

and therefore doctrine/orm & odm package 4.2.9 won't work with 4.2.10 version of doctrine/common ; not sure if it's ok to make such change and add such requirement/conflict between packages

It's okay we just bump the minimal requested version before releasing. But I'm not sure why you'd need such a thing, on what filters do you rely? Are you using the QueryParameter? Just use the name converter?

[VincentLanglet]

But I'm not sure why you'd need such a thing, on what filters do you rely? Are you using the QueryParameter? Just use the name converter?

Because new filters does not support nested parameters natively anymore (cf #7554 and some other issues/discussions), I had to re-implement it myself (sometimes multiple times for different filters) while still trying to make the property generics in order to avoid having too much filters.

While name converter works fine on fooBar -> foo_bar or foo_bar -> fooBar I assume (but I may need to check again) that it's not the case with dots and does not allows the transformation

• fooBar.fooBar -> foo_bar.foo_bar
• foo_bar.foo_bar -> fooBar.fooBar

That why the implode/explode/array_map manipulation is still needed in that case

core/src/Doctrine/Orm/Filter/AbstractFilter.php

Lines 112 to 128 in 4a72073

	protected function denormalizePropertyName(string|int $property): string
	{
	if (!$this->nameConverter instanceof NameConverterInterface) {
	return (string) $property;
	}
	return implode('.', array_map($this->nameConverter->denormalize(...), explode('.', (string) $property)));
	}
	protected function normalizePropertyName(string $property): string
	{
	if (!$this->nameConverter instanceof NameConverterInterface) {
	return $property;
	}
	return implode('.', array_map($this->nameConverter->normalize(...), explode('.', $property)));
	}

and I thought it could be useful to avoid duplicating this "property-dedicated-logic"...