Nils,
I did volunteer to take this on, but just had too busy a week to put much
time into it. Per your earlier example:
ext.config:
foo.bar: 3
I don't think that's equivalent to:
ext.config:
foo:
bar: 3
At least not in Yaml. In the first example, the key is "foo.bar" and just
"foo" in the second. I don't see how the first syntax could let you
override bar without disturbing a value parallel to bar. What extension
were you looking at that processed configs in this format? The example you
gave was in Yaml, but have you considered how the "x.y.z" format would work
in XML or PHP?
In the IRC meeting, I believe we discussed having the configLoad method be
called once, after config arrays were merged by a custom merge() method...
but the take-away may just have been to give configLoad all of the config
arrays and let it do the merging internally.
Ensuring configLoad only got called once would really eliminate the need to
avoid re-loading XML DIC configs on subsequent calls - I'm sure you've seen
many a method start off with "if (!$container->hasDefinition...)". Still,
I'm not sure if it would make the developers job any easier to merge config
arrays.
Every extension seems to have its own standard for the point when parts of
the configuration override each other. Using FrameworkBundle's app.config
as an example, it's not entirely clear without looking at the extension file
if subsequent "validation:" blocks might entirely override each other, or if
their annotation namespace configurations (a few blocks deeper under
"validation:") would merge nicely. There's no real standard for how
extensions in different bundles should handle config arrays, and I feel
there's even less documentation for the end user.
On Fri, Jan 14, 2011 at 7:37 AM, Nils Adermann <[email protected]> wrote:
> Apparently I missed this in last week's IRC meeting's log:
>
> "It was decided that extension loading will be changed that first all
> configs will be collected and then passed to the load() method, which can
> then handle merging and loading. Jeremy offered to take on this task. "
>
> So I guess my suggestion is to at least provide a default merge method,
> which behaves as described which can be overriden if absolutely necessary.
>
>
> On 01/14/2011 01:32 PM, Nils Adermann wrote:
>
>> This thread resulted in https://github.com/fabpot/symfony/pull/133 which
>> seems to be stalled.
>>
>> I'd like to dig this up again because I find writing DI Extensions too
>> complicated compared to how simple it could potentially be.
>>
>> I fail to see the value in the extension's load function being run
>> repeatedly for every configuration. This results in extensions merging
>> configuration in different ways making it difficult to predict what your
>> configuration would have to look like to achieve the expected result.
>>
>> An example:
>>
>> config.yml
>> ext.config:
>> foo:
>> bar: 1
>> zoo: 2
>>
>> config_dev.yml
>> imports:
>> - { resource: config.yml }
>> ext.config:
>> foo:
>> bar: 3
>>
>> The result could either be
>> foo:
>> bar: 3
>> zoo: 2
>> or
>> foo:
>> bar: 3
>>
>> Which one of the two entirely depends on how the extension reads its
>> configuration. Now quite a few extensions I've seen also allow the syntax:
>>
>> ext.config:
>> foo.bar: 3
>>
>> which more intuitively only overwrites the value of foo.bar without
>> touching foo.zoo.
>>
>> So I would like to propose that configuration be merged automatically
>> only passed to the Container Builder a single time. All values would
>> be standardised to the x.y.z format. An array in the second
>> configuration would overwrite the entire array, while an explicit name
>> for an option would replace only that option. This would certainly go
>> further than the suggested patch which only makes this behaviour
>> available to be used as a standard practice in extensions. But I think
>> it would significantly simplify the creation of DIC extensions.
>>
>> Most importantly I would like to hear if there are actual use cases
>> where this behaviour would be problematic? Secondly the question is
>> whether such a deep change is warranted or whether the patch suggested
>> in the pull request is sufficient to standardize this so far, that
>> confusion about the behaviour of configuration will be seldom enough.
>>
>> Cheers
>> Nils
>>
>> On 11/08/2010 03:04 PM, Lukas Kahwe Smith wrote:
>>
>>>
>>> On 24.10.2010, at 11:03, weaverryan wrote:
>>>
>>> c) Since all the OS& core bundles will (should) use XML
>>>> configuration, the config is even less self-documenting. For its
>>>> faults, that was the advantage of YAML in symfony1 - it's free of
>>>> extraneous markup, making it fairly self-documenting. Again, the
>>>> emphasis will need to be on true documentation in Sf2.
>>>>
>>>
>>>
>>> i can accept having different flavors for the config files, but only
>>> if we can really ensure that mixing different flavors works. it seems
>>> like for the template engines we do not expect this to be possible. is
>>> this really going to be possible? can i in the end expect that i can
>>> get a bundle that uses XML to define my model's to be extended by a
>>> YAML config?
>>>
>>> regards,
>>> Lukas Kahwe Smith
>>> [email protected]
>>>
>>>
>>>
>>>
>>
> --
> 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
>
--
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
