I think it would be annoying if i had to have a DI extension way of overriding ALL parameters in my extension. The actual instances %.class for example I always put into parameters only. I think we have to enable developers here to go deep into the internals of an extension instead of us having to write tons of code just to move parameters into the DI extension.
What I do find annoying though is when a configuration option can be defined both through parameters and the DI extension. I found several such "duplicates" in the Doctrine extension and removed them as good I can. Other parameters in the Doctrine extension are now "read-only" for other extensions to consume, i.e. the extension ALWAYS overwrites them with a default value from the extension, so there is no way for you to set the value in "parameters" and have it set this way. greetings, Benjamin On Sat, 22 Jan 2011 19:43:16 -0800, Kris Wallsmith <[email protected]> wrote: > 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
