I agree it's too much for the DIC. k On Feb 3, 2011, at 10:53 AM, Bulat Shakirzyanov <[email protected]> wrote:
+1 on reverting it On Thu, Feb 3, 2011 at 1:49 PM, Fabien Potencier < [email protected]> wrote: > > On 2/2/11 8:34 PM, Johannes wrote: > >> I've now ported most of the SecurityExtension to use the new >> configuration classes. You can find the current state here: >> >> https://github.com/schmittjoh/symfony/blob/config/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Configuration.php >> >> One goal of these classes is to make the configuration more readable/ >> understandable, so if anyone has feedback on the interface, just keep >> it coming. >> > > After merging the new DIC configuration stuff, some people told me their > concerns about adding yet another layer in the DIC. The idea is neat, so I > was waiting for a first implementation to have a better feeling for it. > > And after looking at the first usage (and yes, this is probably the most > complex one), I think we are going too far with this. For me, it's not > understandable anymore. Perhaps it's cleaner than before, but the added > complexity seems very important. > > I don't know what others think, but I'm now i favor of reverting the > introduction if the DIC configuration layer. > > Fabien > > > Kind regards, >> Johannes >> >> >> On 31 Jan., 11:16, Jordi Boggiano<[email protected]> wrote: >> >>> On 31.01.2011 05:02, ryan weaver wrote: >>> >>> * All default option valuesshould be kept in a YAML file. This is the >>>> format that most end-users will use, so having it in its own file means >>>> that there is a real file to reference. This file can also contain >>>> comments and example configuration. For >>>> example:https://github.com/fabpot/symfony/pull/510/files#diff-4 >>>> >>> >>> Great idea. >>> >>> * Each Extension can use this powerful class to specify the options >>>> metadata and then - in theory - be done. The Extension classes can get >>>> back to what they do best: use configuration to configure the DIC. This >>>> will also make those classes considerably more readable, which makes >>>> them more accessible to users who dive through the core code. >>>> >>> >>> Sounds good too, last time I tried to read the security extension it got >>> depressing real quick :) >>> >>> 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 > -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 *e:* [email protected] -- 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 -- 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
