8000 More fine-grained configuration for some core services · Issue #6849 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

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

Closed
fabpot opened this issue Jan 23, 2013 · 7 comments
Closed

More fine-grained configuration for some core services #6849

fabpot opened this issue Jan 23, 2013 · 7 comments

Comments

@fabpot
Copy link
Member
fabpot commented Jan 23, 2013

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).

@stof
Copy link
Member
stof commented Jan 23, 2013

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

@jalliot
Copy link
Contributor
jalliot commented Jan 24, 2013

#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.
Some equivalent feature should be considered for the DI component itself.

/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 ArrayAccess could be great. The LazyServiceSequence could be probably reused as well...

@lsmith77
Copy link
Contributor

i agree that with the tickets mentioned by @jalliot we should be able to address this concern quite elegantly.

@kriswallsmith
Copy link
Contributor

I've proposed finer configuration of the sub-request system in my description of #6871.

@vicb
Copy link
Contributor
vicb commented Jan 25, 2013

@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.

@kriswallsmith
Copy link
Contributor

There is already a DIC tag in place for that. Only core renderers would be configurable in the sub_request block.

@vicb
Copy link
Contributor
vicb commented Jan 25, 2013

Only core renderers would be configurable in the sub_request block.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants
0