Tickets filed: http://www.symfony-project.com/trac/ticket/1494
http://www.symfony-project.com/trac/ticket/1495 On 2/22/07, chtito <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
