This is another bug. It is caused by the fact that an empty entry in a
yml file will be transformed as 'null' and not an empty array, as
might be expected. The problem is then that doing array_merge with
some of the arguments being null returns... null.
All in all i'd say this bug is the result of a combination of silly
behaviours on the part of php and the yml parsers. Still, i believe
this should be fixed in symfony. Please open a ticket for that issue
too.
== Olivier
On 22 fév, 07:35, "David Brewer" <[EMAIL PROTECTED]> wrote:
> Another interesting thing I just noticed is that there is some strange
> behavior in how one config file overrides another. This is most
> easily explained with an example. Let's say I've made a plugin that
> makes use of a parameter 'max_length'. Imagine I'm loading the
> configuration with the prefix of 'my_'.
>
> So, if I have the following in a configuration file in the plugin:
>
> all:
> max_length: 5
> min_length: 3
>
> Then sfConfig::get('my_min_length') returns 3 as expected.
>
> Now let's say that I make a copy of that configuration file and put it
> in the application. But I modify it slightly.
>
> all:
> max_length: 6
> #min_length: 3
>
> This works as expected.
> * sfConfig::get('my_min_length') returns 3
> * sfConfig::get('my_max_length') returns 6, the overridden value.
>
> OK, here's where it gets a bit strange. Let's imagine that I want to
> have the configuration file in my application but with all the values
> commented out -- just to remind me what the defaults are.
>
> all:
> #max_length: 6
> #min_length: 3
>
> If you do this, then neither my_min_length or my_max_length is defined
> anymore. But, if you go a step further and comment out the
> environment:
>
> #all:
> #max_length: 6
> #min_length: 3
>
> Then you get your default values again. It's not a big deal, but it
> seemed like a strange behavior to me.
>
> I just love the configuration system now that I'm getting the hang of
> it! It's great to be able to define your own config files in plugins.
>
> David
>
> On 2/21/07, chtito <[EMAIL PROTECTED]> wrote:
>
> > I totally agree with you, David. I also think a bug should be filed
> > about that.
>
> > == Olivier
>
> > On 22 fév, 02:06, "David Brewer" <[EMAIL PROTECTED]> wrote:
> > > I've started setting up some plugins, and I noticed something which
> > > struck me as being a bit odd. I'm unsure if this behavior is by
> > > design or if it's a bug.
>
> > > What seemed odd to me is that the order of precedence for settings in
> > > config files seems to be: APP trumps PLUGIN trumps PROJECT.
>
> > > I would have expected this to be APP trumps PROJECT trumps PLUGIN.
>
> > > As a concrete example... I have a plugin which contains a custom
> > > config file called config/core.yml. The plugin loads the config file
> > > in its config.php file.
>
> > > If I set up simple test core.yml files in the config directories for
> > > the plugin and the project, with different values for a test
> > > parameter, the value that is available to my pages is the value that
> > > was set in the project's core.yml file. However, if I add another
> > > core.yml file at the application level, then I get the value from the
> > > application's core.yml.
>
> > > What I expected is that a developer would want to set up default
> > > values for the plugin using the configuration file in the plugin's
> > > config file, and then override those values at either the project or
> > > application level.
>
> > > Please let me know if that behavior is not intended, I would be happy
> > > to file a bug.
>
> > > David Brewer
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
