Well, considering how often I still change the interface, that seems a bit premature. As I mentioned during the IRC meeting, it might even be possible to load parts of the configuration, or possibly everything from a YAML file.
However, the interface can only improve if people provide constructive feedback. So far, my feeling is that people have generally a negative attitude towards this, and it seems that they have neither taken some time to play around with it nor have they provided feedback nor have they dealed with a complex configuration. If the Configuration class is not understandable, then the question still remains if it is better/worse than the current state of the SecurityExtension, or in general better/worse than the alternative if we don't have this. My feeling simply is that people haven't invested much time into making an informed decision on this point. I agree that in many cases, you'll be fine with the way it is now (and you won't be required to change it), but I honestly like to see one of the persons who now vote to remove it add merging support to the SecurityExtension. Kind regards, Johannes On Thu, Feb 3, 2011 at 7:56 PM, Kris Wallsmith < [email protected]> wrote: > 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]> > [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> >>> 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> >>>>> 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/>http://seld.be/ >>>> >>> >>> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at <http://symfony-project.com>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]> >> [email protected] >> To unsubscribe from this group, send email to >> <symfony-devs%[email protected]> >> [email protected] >> For more options, visit this group at >> <http://groups.google.com/group/symfony-devs?hl=en> >> http://groups.google.com/group/symfony-devs?hl=en >> > > > > -- > *Bulat Shakirzyanov* | Software Alchemist > > *a: *about.me/avalanche123 > *e:* <[email protected]>[email protected] > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at <http://symfony-project.com>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]> > [email protected] > To unsubscribe from this group, send email to > <[email protected]> > [email protected] > For more options, visit this group at > <http://groups.google.com/group/symfony-devs?hl=en> > 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
