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]>[email protected]
<mailto:[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]>[email protected]
<mailto:[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]
<mailto: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]
<mailto: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
