On 1/22/11 9:16 PM, ryan weaver wrote:
Hey guys-
As you all know, the DIC works by building a configuration of services
based on a set of parameters. Nothing is dumped or decided until *all*
configuration is taken into account. This means that I can change the
"request_listener.class" parameter at the last second, and have it
reflected in the container.
Some parameters, act differently. For example, the
"doctrine.odm.mongodb.auto_generate_proxy_classes" parameter is used to
set a method call on a service. The logic for this occurs in the DI
extension itself, not inside some DI resource (http://bit.ly/hH8C3I).
Unlike the traditional parameters, these parameters must be overridden
in a different way:
# this works as the DI extension is programmed to merge this in
doctrine_odm.mongodb:
auto_generate_proxy_classes: true
# does not work as the value of the parameter has already been consumed
by the DI extension
parameters:
doctrine.odm.mongodb.auto_generate_proxy_classes: true
You are talking about two very different things.
DIC parameters are just key/value pairs. These parameters are the
variables used by services.
An extension defines options to expose parameters and services through a
semantic interface. There is no relation between these options and the
parameters. Of course, sometime you have an option that has the same
name as a parameter, but that does not need to be the case.
Developers should always use the DIC extension to configure extensions.
So, they need to be aware of the available options, not the parameters.
Parameters are more low-level and should not be used if there is a DIC
extension.
Of course, when you define your own services and parameters, the story
is different. In that case, you don't need to create an extension
(except if you want to distribute your code). So, parameters become the
way you can tweak your services.
Fabien
Here's the problem: For any DI extension resource file, *some*
parameters can be overridden normally (e.g. request_listener.class)
while others must be overridden in this custom way
(e.g. doctrine.odm.mongodb.auto_generate_proxy_classes). This makes
documentation and understanding difficult.
For the parameters that are consumed manually by a DI extension (i.e.
not truly used by the DIC), I propose that they're removed from the DI
extension resources and put into the DI extension class itself. This
means that *all* parameters left in any DI resource can be overridden
under the traditional "parameters" section. Any "custom" DI extension
"options" would live and be documented inside the DI extension class itself.
Thoughts? Objections? Am I totally wrong?
Thanks :)
Ryan Weaver
Lead Programmer - iostudio - Nashville, TN
http://www.iostudio.com
http://www.thatsquality.com
Twitter: @weaverryan
--
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
--
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
