Leverage targeted resolvers #773
Conversation
| $container->getDefinition('doctrine_mongodb.odm.entity_value_resolver')->setArgument(2, (new Definition(MapEntity::class))->setArguments([ | ||
| null, | ||
| null, | ||
| null, | ||
| $controllerResolverDefaults['mapping'] ?? null, | ||
| null, | ||
| null, | ||
| null, | ||
| null, | ||
| $controllerResolverDefaults['disabled'] ?? false, | ||
| ])); |
There was a problem hiding this comment.
Does the container support named arguments? That might make this a little easier to read.
| <argument type="service" id="doctrine_mongodb" /> | ||
| <argument type="service" id="doctrine_mongodb.odm.entity_value_resolver.expression_language" on-invalid="ignore" /> | ||
| <tag name="controller.argument_value_resolver" priority="110"> | ||
| <attribute name="name">Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver</attribute> |
There was a problem hiding this comment.
should be:
<tag name="Symfony\Bridge\Doctrine\ArgumentResolver\EntityValueResolver" priority="110">controller.argument_value_resolver</tag>
There was a problem hiding this comment.
Actually NO: this name would conflict with https://github.com/doctrine/DoctrineBundle/blob/2.9.x/Resources/config/orm.xml#L194 so we need to find another one
There was a problem hiding this comment.
On second though, this name might be the right one. It should allow #[MapEntity] to work correctly. I don't know how one would expect this to resolve the conflict when there is both ORM + MongoDB but I'd be tempted to say this should be handled inside EntityValueResolver (it could decide on its own which manager to use.)
There was a problem hiding this comment.
IIUC using Symfony 6.3 (with pinned resolvers), #[MapEntity] extending ValueResolver will set EntityValueResolver::class as resolver, but there won't be any resolver named EntityValueResolver::class, even if you are only using ORM, there will be doctrine.orm.entity_value_resolver but not EntityValueResolver::class, so using #[MapEntity] without specifying the resolver will probably fail?
Update: now I see that the ORM will also set its doctrine.orm.entity_value_resolver with name EntityValueResolver and there is when the conflict will happen.
There was a problem hiding this comment.
The resolver it registered under its FQCN, see name attribute on the tag in the XML I linked above.
| $mapEntityDefinition = $container->getDefinition('doctrine_mongodb.odm.entity_value_resolver.map_entity'); | ||
|
|
||
| $mapEntityDefinition->setArgument('$mapping', $controllerResolverDefaults['mapping'] ?? null); | ||
| $mapEntityDefinition->setArgument('$disabled', $controllerResolverDefaults['disabled'] ?? false); |
There was a problem hiding this comment.
@alcaeus I've registered the service doctrine_mongodb.odm.entity_value_resolver.map_entity previously and this is another way to only set some parameters, not sure if this is recommended though since if the name of the argument is changed, this will fail.
|
We are kind of stuck in here, the problem is that with targeted value resolvers, In our side, the only thing I can think of is to create a |
@franmomu imo this would make the most sense to do |
Closes #770
Symfony allows array attributes for services tags since 6.2: symfony/symfony#47364