Blind deep merging would be something like array_merge_recursive(), which I
wouldn't consider doing. By asking about "deep merging", I was inquiring at
which point hierarchies in the config array should override each other.
For something like "templating", the only non-scalar child options are
engine/engines and loader, which may each be one or multiple values
("engine" uses the normalize helper method for that). These two would
require intelligent merging but for other scalar options I assume the merge
logic when iterating across $configs would be "later overrides previous".
Do we have a convention for disabling a configuration block? I've seen
other extensions use a value of "false" to disable an entire block. So if
the first config processed had "templating: { ...big config... }", and the
second had "templating: false", I think the user's intention would be for
"false" to override the previous configuration.
On Mon, Jan 24, 2011 at 4:25 PM, Fabien Potencier <
[email protected]> wrote:
> On 1/24/11 10:20 PM, Jeremy Mikola wrote:
>
>> Here is my current progress on FrameworkExtension:
>> https://github.com/fabpot/symfony/pull/486
>>
>> I suppose it could use some feedback as to what options should support
>> deep merging (e.g. validation annotations array)? At the moment,
>> top-level config options override each other.
>>
>
> I had a quick look and the merging is wrong. You cannot deeply merge
> blindly. So you probably do that for simple key/values, but not for things
> like "router" or "templating".
>
> Fabien
>
--
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
