-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose ResolveTargetDocumentListener in configuration #197
Conversation
@kingcrunch: Is this ready to be used? |
@fixe Uff ... Thats a while ago. If it doesn't conflict with alter changes there should be no problem. |
It will work with the master branch. BETA10 just isn't tagged yet. |
I can't get it to work actually. I can't find where/how this tag "doctrine_mongodb.event_listener" is processed. |
ODM BETA10 is tagged, so I'll try to get to this within the coming week. |
Thanks for the update |
@jmikola 👍 |
We definitly need this patch :) Any issue I can work on to make it merged quickly? |
if ($config['resolve_target_documents']) { | ||
$def = $container->findDefinition('doctrine_mongodb.odm.listeners.resolve_target_document'); | ||
foreach ($config['resolve_target_documents'] as $name => $implementation) { | ||
$def->addMethodCall('addResolveTargetDocument', array($name, $implementation, array())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just dropping an open question here: why not wrapping the $implementation
inside a Symfony\Component\DependencyInjection\Parameter
in case the container has this parameter?
This would allow to open some interesting extension point, especially when overriding a bundle document object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use case is to allow configuring resolved documents like so:
# app/config/config.yml
resolve_target_documents:
Acme\Bundle\Model\BookInterface: acme.document.book.class
# services.yml
parameters:
acme.document.book.class: Acme\Bundle\Document\Encyclopedia
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd require to move this service definition modification inside a compiler pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And also provide the same behaviour for DoctrineBundle
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gquemener wrapping it in a Parameter
instance forces it to be a parameter, which is likely to be wrong. Witht he current implementation, you can use parameters by using the %foo%
syntax, which will be resolved in the method call argument
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, %foo%
syntax should do it!
Expose ResolveTargetDocumentListener in configuration
👍 Thanks |
@gquemener: A new tag for the bundle is imminent; I'd just like to take care of #235 first. |
@ludofleury In case you haven't figured that out for 5 months, the event_listener/subscriber tags are processed in a compiler pass defined in the Symfony Doctrine Brige (not in Doctrine Bundle). I found it confusing too last week, but @stof showed me the way: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php |
Supersedes #196, but depends on doctrine/mongodb 1.0.0-BETA10 tag.