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]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
