Sent from my Nexus One On Jan 26, 2011 10:14 AM, "Fabien Potencier" < [email protected]> wrote: > On 1/26/11 4:02 PM, weaverryan wrote: >> 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. > > A pull request is always better than a thousand words. Now I understand > what you meant in a previous email. > > Please, go ahead and modify the MongoDB extension so that we can see all > the benefits. > > Thanks, > Fabien > >> 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%[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%[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%[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
