Based on some feedback from Bernhard, and Jeremy, I've updated the wording of some methods. Let me know what you think: https://github.com/schmittjoh/symfony/blob/config/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Configuration.php
If there is something unclear, it would be interesting to know which parts exactly are not understandable and need more shaping. Kind regards, Johannes On Thu, Feb 3, 2011 at 11:56 PM, Fabien Potencier < [email protected]> wrote: > > On 2/3/11 10:14 PM, Jeremy Mikola wrote: > >> Fabien: to what state are you suggesting we revert? >> > > I was just talking about the new Configuration classes of the DIC I merged > some days ago. > > 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] >> <mailto:[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] >> <mailto:[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] <mailto:[email protected]>> wrote: >> >> +1 on reverting it >>> >>> On Thu, Feb 3, 2011 at 1:49 PM, Fabien Potencier >>> <<mailto:[email protected]> >>> [email protected] >>> >>> <mailto:[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] >>> <mailto:[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 >>> <http://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 >>> <mailto:[email protected]> >>> [email protected] >>> <mailto:[email protected]> >>> >>> To unsubscribe from this group, send email to >>> >>> <mailto:symfony-devs%[email protected]<symfony-devs%[email protected]> >>> >[email protected]<symfony-devs%[email protected]> >>> >>> <mailto:[email protected]<symfony-devs%[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 <http://about.me/avalanche123> >>> *e:* <mailto:[email protected]>[email protected] >>> <mailto:[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 >>> <http://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 >>> <mailto:[email protected]> >>> [email protected] >>> <mailto:[email protected]> >>> >>> To unsubscribe from this group, send email to >>> >>> <mailto:[email protected]<symfony-devs%[email protected]> >>> >[email protected]<symfony-devs%[email protected]> >>> >>> <mailto:[email protected]<symfony-devs%[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 >> <http://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] <mailto: >> [email protected]> >> >> To unsubscribe from this group, send email to >> >> [email protected]<symfony-devs%[email protected]> >> >> <mailto:symfony-devs%[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 <http://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] >> <mailto:[email protected]> >> >> To unsubscribe from this group, send email to >> >> [email protected]<symfony-devs%[email protected]> >> >> <mailto:symfony-devs%[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]<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 > -- 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
