Fabien: to what state are you suggesting we revert? If you mean the old system of calling configLoad() once for each encountered configuration and bypassing the ability to merge configs at all, I think that's a step backwards. The changes Ryan and I made with MongoDB and Framework extensions, respectively, were done before Johannes' implementation, but even our "primitive" changes cleaned up the extensions quite a bit.
Security is arguably more complex than anything else right now, so while I admittedly haven't had time to review Johannes' work yet, I acknowledge that he probably had some significant challenges before him to warrant such an implementation. Looking at fabpot/master as of a week ago, the state of merging security configurations is quite poor - to the point where our dev, test and prod environments each need their own full security.config blocks (foregoing DRY at the moment). On Thu, Feb 3, 2011 at 2:29 PM, Johannes Schmitt <[email protected]>wrote: > 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]<symfony-devs%[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
