Wire up type aliases support in EntityValueResolver #1790
Conversation
| if (class_exists(EntityValueResolver::class)) { | ||
| $valueResolverReflection = new ReflectionClass(EntityValueResolver::class); | ||
|
|
||
| if ($valueResolverReflection->hasMethod('addTypeAlias')) { |
There was a problem hiding this comment.
I think using a constructor argument instead of an adder can save us from using reflection at all. WDYT?
There was a problem hiding this comment.
Initially that is what I tried to do, but I figured explicitly checking support without depending on constructor argument count and order was more desirable. This also seems more in line with other parts of the extension which also call add* or set* methods. I do agree that reflection is generally undesirable.
Having this as a method also allows for easier extension of the ValueResolver beyond the bundle, since the property holding this mapping is otherwise private; although this can also be achieved with explicit service configuration in the framework.
Also, setting the argument on its position by key doesn't seem to work. Replacing the reflection code in this PR with the following snippet:
$valueResolverDefinition->setArgument(3, $config['resolve_target_entities']);Results in an error: TypeError: Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver::__construct(): Argument #3 ($defaults) must be of type Symfony\Bridge\Doctrine\Attribute\MapEntity, array given
Even when using 4 in the above code snippet. Using explicit argument names (->setArgument('$typeAliases', ...)) doesn't work as this causes a container compilation error on older bridge versions because the argument does not exist; this would break backwards compatibility (or still need reflection to check the existance of the property/argument).
There was a problem hiding this comment.
for add an argument, I think you can remove the condition if ($controllerResolverDefaults) { at l.527 for always declare the mapentity (with default arguments) as arg 2 and then you can decalre a argument 3.
There was a problem hiding this comment.
@NanoSector up to give @eltharin's suggestion a try?
There was a problem hiding this comment.
@nicolas-grekas Sorry, these PRs must have fallen off my radar. I've rebased them on the latest development branches and applied your and @eltharin 's suggestions.
NanoSector
force-pushed
the
feature/type-aliases-support
branch
from
f748096 to
18f1ca0
Compare
This is an addendum to PR symfony/symfony#51765 in the Symfony Doctrine Bridge, which adds type alias support to EntityValueResolver. This code injects the doctrine.orm.resolve_target_entities configuration into the EntityValueResolver class.
NanoSector
force-pushed
the
feature/type-aliases-support
branch
from
18f1ca0 to
142a3df
Compare
|
@ostrolucky Sorry to bother you, I am wondering if any action is required on my part, considering the PR still has 'on hold' status? Its Symfony counterpart is marked as ready. |
|
It's onhold because upstream PR is not merged yet |
ostrolucky
force-pushed
the
2.13.x
branch
3 times, most recently
from
abb5de0 to
2983fa7
Compare
ostrolucky
force-pushed
the
2.13.x
branch
2 times, most recently
from
01c7700 to
7bfb8e8
Compare
This is an addendum to PR symfony/symfony#54545 targeted at issue symfony/symfony#51765 in the Symfony Doctrine Bridge, which adds type alias support to EntityValueResolver.
This code injects the doctrine.orm.resolve_target_entities configuration into the EntityValueResolver class.