Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[DependencyInjection] fixed service resolution for factories#13519
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
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.
FWIW, I think it was a mistake to support this use case, but as it is, we should support it thoroughly.
76ccf15 to5778721CompareThere 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.
do we really need this logic here ? I don't understand the goal of the$ check changing the way to dump things.$definition->getFactoryService() will always return a service id here, given you resolve it in the 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.
btw, do we really need to support the case of parameters for factory services ? I does not make sense IMO. This is a use case for aliases instead.
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.
IIRC, it's because it's supported by the new way of defining factories. But you're right, it does not really make sense. I'm going to drop this.
xabbuh commentedMar 11, 2015
59b8137 tof86ad95Comparefabpot commentedMar 11, 2015
I've removed some code, should be ready now. ping @symfony/deciders |
…es (fabpot)This PR was merged into the 2.3 branch.Discussion----------[DependencyInjection] fixed service resolution for factories| Q | A| ------------- | ---| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets |#13455| License | MIT| Doc PR | n/aIn the service container, factories can be defined with a class/method pair or a service/method pair.The class or service value can be a container parameter, but it was not supported everywhere, this PR fixes that.Note that the method can never be a container parameter as this is supported nowhere in the current code, so this has not been changed.Another PR will fix the 2.6 way of configuring a factory.Commits-------f86ad95 [DependencyInjection] fixed service resolution for factories
This PR was merged into the 2.3 branch.Discussion----------Fixing wrong variable name from#13519| Q | A| ------------- | ---| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets |#13519| License | MIT| Doc PR | n/aHi guys!I'm currently seeing an undefined variable in the `PhpDumper` on all branches. I think it was added inadvertently in#13519, so unless I'm totally missing something, this should be an easy merge.Thanks!Commits-------3ae52ed Fixing wrong variable name from#13519
* 2.3: `ResolveParameterPlaceHoldersPass` unit tests Fixing wrong variable name from#13519
* 2.6: `ResolveParameterPlaceHoldersPass` unit tests Fixing wrong variable name from#13519 [translation][initialize cache] Remove dead code.Conflicts:src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
…factories (xabbuh)This PR was merged into the 2.6 branch.Discussion----------[DependencyInjection] resolve class parameters in service factories| Q | A| ------------- | ---| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets || License | MIT| Doc PR |This is based on the parameter resolving for factories from#13519 and makes the necessary changes for the new factory syntax introduced in Symfony 2.6.@fabian In#13519, you also updated the `PhpDumper` to make use of `dumpValue()`. Should I do the same here (or in this case reopen#13455)?Commits-------8bda37c resolve class parameters in service factories
* 2.7: `ResolveParameterPlaceHoldersPass` unit tests Fixing wrong variable name from#13519 [translation][initialize cache] Remove dead code. [DependencyInjection] fixed service resolution for factories [HttpKernel] Throw a LogicException when kernel.exception does not led to a Response [FrameworkBundle] Added domain column when debugging translations [PhpUnitBridge] do not replace but require-dev in symfony/symfony [acl][command][SecurityBundle] Fixed user input option mode to be an ArrayConflicts:composer.json
In the service container, factories can be defined with a class/method pair or a service/method pair.
The class or service value can be a container parameter, but it was not supported everywhere, this PR fixes that.
Note that the method can never be a container parameter as this is supported nowhere in the current code, so this has not been changed.
Another PR will fix the 2.6 way of configuring a factory.