Hello everyone,
I want to drop something into the current state of affairs that I think
has to be addressed in the Dependency Injection Container. Being a DIC
user for several years (and written my own) I realized several problems.
I have a proposal for this very advanced feature for the DIC, but i
think we should add it. It would be completely optional for anyone to
use, but for more complex projects it would really make sense.
Problem 1: One Service Id only has one static implementing class
Say we have a Templating Service id "templating" and a class
"MyTemplateEngine". This is used throughout your project whenever a
controller needs a template engine. Now someday you have a need for a
second "MyNewTemplateEngine", but you don't want to replace the old one
for all the old controllers.
The DIC Factory option is a possible solution here, but the DIC
container is a pattern to avoid having to write factory classes. Why
starting again?
Problem 2: In a modular application (Symfony Bundle) two components
overwrite the same basic service in an incompatible way.
Both problems boil down to the same solution: You want to be able to
inject different service implementations based on which "parent" service
is requested.
The DIC should be able to be a more complex factory (with a non-linear
execution path based on state variables called "context". Another angle
would see this proposal as "subnamespaces for a service". They allow to
have IF, ELSEIF, ELSE kind of logic to return different services with
the same service-id.
Three new methods:
1. Container::addContext($name, $priority = 0)
2. Container::activateContext($name)
3. Container::deactivateContext($name)
Then have a configuration for this in the XML (pseudo, any other form
would also work)
<services>
<service id="mybundle.mycontroller" class="FooController">
<argument type="service">
<service id="templating" />
</argument>
</service>
<service id="templating" class="DefaultTemplateEngine" />
<service id="templating" context="json" class="JsonTemplateEngine" />
<service id="templating" context="xml" class="XmlTemplateEngine" />
<service id="response" context="mybundle" class="MyBundleResponse" />
</services>
The Container::getService() method would then have to account for the
currently activated contexts and pick the right service to instantiate.
One powerful Integration Point that I see: Allow to activate a contexts
depending on the Route, pseudo config code:
foo:
pattern: /foo.:_format
defaults: { _controller: FooController:indexAction, contexts: ["mybundle",
":_format"] }
What do you think?
This is now just out of my mind and with a little bit of input from
Google Guice DIC and the #symfony-cmf channel. However for such a
powerful feature we should definately also look at Spring DIC or other
well known containers for help.
greetings,
Benjamin
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
