I've just created a pull request on the DoctrineMongoDBExtension as a proof of concept: https://github.com/fabpot/symfony/pull/510
As I said in the comment, I think that using $container- >getParameter() inside a DI extension class should be illegal (from a best-practice standpoint). Parameters used in this way aren't really parameters at all, they're options on the DI extension class. Unlike normal parameters, they can't be configured under the "parameters" key. I think that these "options" should be what's modifiable via the DI extension configuration (e.g. values beneath doctrine_odm.mongodb). They should be removed from the DI extension resource entirely. This will create a very clear line between the DI extension "options" and the normal DIC parameters. This is important because each is configured in a different way. Thoughts? Shall I take the pull request further by removing these faux- parameters (e.g. "doctrine.odm.mongodb.default_connection") and making them options on the DI extension class? The options would be PHPDoc'ed on mongodbLoad(), making the DI extension options very easy to document. Thanks! On Jan 23, 3:51 am, Benjamin Eberlei <[email protected]> wrote: > 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/D... > > > > > > > > > > > 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%2Bunsubscribe@google > groups.com>>>> 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%2Bunsubscribe@google > groups.com> > > > > > > > > > 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
