Symfony bundles allow you to set a parent on each Bundle. Sadly enough each Bundle can only have 1 child. This means that it's impossible for 2 modules to set "CoreBundle" as their parent at the same time. I'm prety convinced more than one module will override some core systems defined in CoreBundle.
The patch fixes this by overriding/modyfing the kernel "initializeBundles" method. Basicly it extends the current code with a recursive function to account for multiple children.
So 80% of the code in this patch is just copied from symfony don't blame me for that :p
We than can use the builded dependency graph to call the Bundles in the correct order. This all sounds complicated, I know :).
I need help on the exception handling, I don't have an idea how to do it properly.
| Comment | File | Size | Author |
|---|---|---|---|
| multiple-parenting-bundles.patch | 4 KB | aspilicious |
Comments
Comment #1
aspilicious commentedbetter title
Comment #2
Crell commentedLeaky coding standards. :-)
16 days to next Drupal core point release.
Comment #3
aspilicious commentedCrosspost
Comment #4
katbailey commentedWe need to be really clear about what our goal is with this issue. Looking at the symfony docs on overriding the various parts of a bundle (http://symfony.com/doc/current/cookbook/bundles/override.html) it looks like this inheritance idea is for templates and controllers and other non-service things provided by bundles.
For overriding service definitions, if the class name is not provided as a DIC parameter, then compiler passes are the way to go. Either way there is no need for bundle inheritance here.
Given that the only thing we use bundles for at the moment is to provide service definitions (and attach them as event listeners or whatever), I'm a little unclear as to what we need a change like this for at this point.
In fact, the more I think about it, the more it seems to me that our use of Symfony bundles perhaps ought to be restricted to just the DIC registration mechanism. The rest of what a bundle is in symfony-land really doesn't seem to me to correspond to what a Drupal module is at all. It's more like a feature (as in Features module).
Maybe I'm not seeing the big picture here - would love to hear other people's thoughts on this.
Comment #5
aspilicious commentedSo you're saying we shouldn't change things added to the dic by CoreBundle for example?
Comment #6
katbailey commentedNo, I'm saying that any and all module bundles can already change anything that CoreBundle provides, because all it provides now are services. And a bundle does not need to be a child of CoreBundle in order to override the services it provides. So it is not clear to me what problem the allowing of multiple children per bundle is actually solving.
Comment #7
aspilicious commentedAfter discussing this in irc, I'm going to postpone this. We can change services with a compiler pass but at the moment we don't compile the container. When we have done that this issue is a won't fix.
More information can be found on symfony doc pages:
http://symfony.com/doc/current/cookbook/service_container/compiler_passe...
http://symfony.com/doc/current/components/dependency_injection/compilati...
http://symfony.com/doc/current/cookbook/bundles/override.html
http://symfony.com/doc/current/cookbook/bundles/inheritance.html
Comment #8
jbrown commentedSo Symphony brings in something called Bundles? We need to stop using that term for Entity Types: #1380720: Rename entity "bundle" to "subtype" in the UI text and help
Comment #9
Crell commentedIs anything still happening here? Does it need to?
Comment #10
katbailey commentedNope :-)