-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
More fine-grained configuration for some core services #6849
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
Comments
loaders for the service container cannot be configured in the config (as they are used to read this config). Thus, removing a loader will not have any real impact on performances as they are used at compile time only |
#6140 (and related issues/PRs like #5012 for instance) and JMSDiExtraBundle's lazy service collections should be considered IMO. They can probably not be used as is but are a first step towards a really lightweight DI that only loads what is absolutely required. /cc @schmittjoh @lsmith77 EDIT: I guess JMS\DiExtraBundle\DependencyInjection\Collection\LazyServiceMap could be easily used as inspiration. Creating an equivalent class in core without the dependency on @schmittjoh's phpcollection library and by implementing |
i agree that with the tickets mentioned by @jalliot we should be able to address this concern quite elegantly. |
I've proposed finer configuration of the sub-request system in my description of #6871. |
@kriswallsmith your proposal does not specify how you could dynamically add an handler (which should also be configurable). A good example of this is the security bundle and the config factories. |
There is already a DIC tag in place for that. Only core renderers would be configurable in the |
Why should we limit to only core renderers ? You might also want to override some of them with handlers supporting more config options. It might be overkill in such a case but that is something to keep in mind when crafting a generic solution. |
For some services that accept an array of other objects (like loaders for the translator, or loaders for the service container, or strategy for the HTTP content renderer), Symfony automatically registers all available build-in "objects/services" and there is no simple way to restrict them to just a few.
We might want to make that configurable (to improve performance for instance, or to explicitly remove some features).
The text was updated successfully, but these errors were encountered: