This is a bug, IMO. The app developer should be able to set a parameter to override an extension's default parameters. Likewise, a service defined in the app config should override one defined in an extension with the same id.
Fabien, do you see it differently? Is an extension's config array a public API and the parameters used internally part of a private API? If so, the extension's parameters should never be merged back into the container, and the parameter bag never passed to the temporary container here… https://github.com/fabpot/symfony/blob/master/src/Symfony/Component/DependencyInjection/Compiler/MergeExtensionConfigurationPass.php I think the solution is to fix this compiler pass so it respects parameter and services set by the app dev. Thanks Ryan! k On Jan 22, 2011, at 3:45 PM, ryan weaver <[email protected]> wrote: Ok, so my understanding has come full circle. Yes, it sucks that certain parameters in DI extension resources can't be overridden as normal parameters (since they're consumed by the DI extension class itself). But, as Fabien said, you shouldn't be doing this in the first place, and if you are - you're on your own. Plus, I found that removing these "special" parameters seemed inconsistent. Many of these parameters are consumed by the DI extension simply due to the nature of the way the related service is created. So, splitting information between the DI resource parameters and a new "options" array on the DI extension seemed unnatural. So, this was a learning experience on my part. As Fabien said, the options exposed by a DI extension should be configured and "never" the parameters located in any resource loaded by the DI extension. The point is, if you need to override the parameters from a DI extension, you're "on your own". The options exposed by the DI extension should be enough (and well-doc'ed). Thanks for the help! Ryan Weaver Lead Programmer - iostudio - Nashville, TN http://www.iostudio.com http://www.thatsquality.com Twitter: @weaverryan On Sat, Jan 22, 2011 at 4:14 PM, ryan weaver <[email protected]> wrote: > Yes, Jordi, you understand me perfectly. I'm seeing this in the MongoDB > bundle, but perhaps the "bad practice" isn't very rampant. I'll put together > a pull request removing some of these parameters and state my case there. > > Fabien, I suppose the documentation should *just* document the available > "options" of a DIC and leave the discovery that lower-level things could be > overridden (such as service class names) to the advanced developer. That > gives me good "philosophical" direction as well. > > Thanks! > > Ryan Weaver > Lead Programmer - iostudio - Nashville, TN > http://www.iostudio.com > http://www.thatsquality.com > Twitter: @weaverryan > > > On Sat, Jan 22, 2011 at 3:23 PM, Jordi Boggiano <[email protected]>wrote: > >> On 22.01.2011 21:50, Fabien Potencier wrote: >> > 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. >> >> I think he's onto something. If the "config.xml" files define parameters >> that are actually just used by the Extension class and then discarded, I >> think this leads to false expectations that you can define the parameter >> in your config file and override some value. >> >> It's just a best practice thing, but I think it makes sense that a >> parameter that is only accessible via the Extension config block should >> not be defined as a parameter in the DIC config. I have no idea how >> common this "bad practice" is at the moment though. >> >> Cheers >> >> -- >> Jordi Boggiano >> @seldaek :: http://seld.be/ >> >> -- >> 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]<symfony-devs%[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]<symfony-devs%[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
