Alright, forget this then, seems like it's not worth it to remove them. For namespacing services I tend to use bundlename.type.classname, but that's nothing special.
On Fri, Jan 14, 2011 at 9:46 PM, Jeremy Mikola <[email protected]> wrote: > In our own Symfony2 app, we make good use of support for multiple extension > load methods. Most bundles may only use config, but I think the feature > itself is worth keeping around. > > Consider a bundle with a really massive configuration... you could certainly > do everything within a single config method, but the current system allows > the developer to break things up into separate methods. I personally have > main.validatiors to activate my custom validators, and main.security for my > security add-ons. Smaller load methods makes unit testing them easier - > although that's a personal preference. > > I suppose I could have used FrameworkBundle as an example, but that's one > bundle with two extensions both with configLoad methods. > > I'm a bit concerned that we don't have very good namespacing, however the > same problem exists with service ID's I suppose. > > On Fri, Jan 14, 2011 at 7:09 AM, Jordi Boggiano <[email protected]> wrote: >> >> Heya, >> >> I am wondering if it really makes sense to have: >> >> twig.config: >> orm.config: >> ext.config: >> >> .. I see the point that one extension could have more than configLoad(), >> it could have fooLoad() and then use: >> >> ext.foo: >> >> But.. is it really useful? It seems that everyone more or less >> standardized on using *.config, so imo we could remove it and let it >> just be: >> >> twig: >> orm: >> ext: >> >> What do you think? >> >> Of course the only problem is if someone names their extension >> parameters or services, then it conflicts, but we could easily mark >> those as reserved. >> >> There is also the case of XML, where twig.config is twig:config, which >> is a namespace; I guess in that case it makes a bit more sense, but I'm >> not sure what it'd mean to remove the namespace. Losing XSD capability? >> >> 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] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en > > > > -- > jeremy mikola > > -- > 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 > -- 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] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
