Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 Apr 2014 at 02:27 UTC
Updated:
29 Jul 2014 at 23:32 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
pwolanin commented1st pass patch.
Comment #2
pwolanin commentedTim suggests avoiding an API change by keeping having both interfaces in place for this class.
Comment #3
dawehnerCan we find a beter name, maybe just BreadcrumbManagerInterface
Btw. I would love to extend the BreadcrumbBuilderInterface instead
Comment #4
pwolanin commentedSo, to me it doesn't make any sense to extend the other interface - they are really independent.
I *think* this manager was sing the builder interface since someone had an idea it might be chained? I'd be ha[[y to remove the builder interface from it, but Tim thought that was an APi change.
Calling the interface Manager vs. Service doesn't matter much to me, but it's the method that called during the compiler pass that makes it distinct, so it seemed service specific.
Comment #5
dawehner'service' tells you not a single information. On the other hand I don't get 100% why we need to add addBuilder to this interface. This method
is coupled to the container pass, much like the container configuration itself. So if you configure the container different you should kind of know what you are doing.
On the other hand I would be 100% fine to break the API here, ... it is pointless.
Comment #6
pwolanin commentedSo, I think the addBuilder should be part of the interface since if I substitute a different class in mymodule.services.yml it needs to work properly when used in that compiler pass. Doing that as an exercise for a presentation was what made me realize there was not a useful interface.
In the compiler pass it does:
So it's de-coupled from the concrete class that's behind that service name.
Comment #7
pwolanin commentedThis renames the interface and documents the exception and makes the manager just implement the manager interface.
Also, there is a small but obvious optimization that we should pre-sort the builders, rather than re-sorting them on every page request.
Comment #8
Crell commentedThe build() method is not irrelevant. By design, you can swap in a single breadcrumb builder in place of the COR object and everything still works. In fact, the breadcrumb block interacts with the system via the build() method. That is the required method. See http://palantir.net/blog/d8ftw-hacking-core-without-killing-kittens
If we're going to add an interface, we probably want something better than "manager". I'd suggest ChainBreadcrumbInterface, since it's the same Chain of Responsibility as ChainRouter. That should extend BreadcrumbBuilderInterface, since it has to present the same "I'm just a builder" image to the rest of the world.
Comment #9
pwolanin commentedok, here you go.
Comment #10
dawehnerNot really. ... it uses the one which applies but asks in the order of the builders.
Comment #11
Crell commentedMuch nicer! #10 should be addressed but otherwise the code looks fine to me.
Comment #12
pwolanin commentedhow about this?
Comment #13
dawehnerGreat, thank you!
Comment #14
tim.plunkettYou meant this, right? :)
Comment #15
webchickNot a huge fan of "ChainBreadcrumbBuilderInterface" TBH, but #8 points out that we already do this with ChainRouter, so I guess that's fair.
Committed and pushed to 8.x. Thanks!