-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Routing] removed tree structure from RouteCollection #6120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
What benefit of this? |
@Koc Why did you not simply wait for the description? ^^ |
i love PR that remove more code than they add whithout removing functionality. |
There's an issue somewhere in Drupal where we're trying to use addCollection() as a shorthand for iterating over one collection and calling add() on the other for each item. We can't do that, however, because the subcollections are not flattened properly when reading back and our current dumper can't cope with that. So this change would not harm Drupal at all, and would mean I don't have fix a bug in our dumper. :-) I cannot speak for any other projects, of course. |
Ok, this is ready. |
This PR was merged into the master branch. Commits ------- 51223c0 added upgrade instructions 50e6259 adjusted tests 98f3ca8 [Routing] removed tree structure from RouteCollection Discussion ---------- [Routing] removed tree structure from RouteCollection BC break: yes (see below) Deprecations: RouteCollection::getParent(); RouteCollection::getRoot() tests pass: yes The reason for this is so quite simple. The RouteCollection has been designed as a tree structure, but it cannot at all be used as one. There is no getter for a sub-collection at all. So you cannot access a sub-collection after you added it to the tree with `addCollection(new RouteCollection())`. In contrast to the form component, e.g. `$form->get('child')->get('grandchild')`. So you can see the RouteCollection cannot be used as a tree and it should not, as the same can be achieved with a flat array! Using a flat array removes all the need for recursive traversal and makes the code much faster, much lighter, less memory (big problem in CMS with many routes) and less error-prone. BC break: there is only a BC break if somebody used the PHP API for defining RouteCollection and also added a Route to a collection after it has been added to another collection. So ``` $rootCollection = new RouteCollection(); $subCollection = new RouteCollection(); $rootCollection->addCollection($subCollection); $subCollection->add('foo', new Route('/foo')); ``` must be updated to the following (otherwise the 'foo' Route is not imported to the rootCollection) ``` $rootCollection = new RouteCollection(); $subCollection = new RouteCollection(); $subCollection->add('foo', new Route('/foo')); $rootCollection->addCollection($subCollection); ``` Also one must call addCollection from the bottom to the top. So the correct sequence is the following (and not the reverse) ``` $childCollection->->addCollection($grandchildCollection); $rootCollection->addCollection($childCollection); ``` Remeber, this is only needed when using PHP for defining routes and calling methods in a special order. There is no change required when using XML or YAML for definitions. Also, I'm pretty sure that neither the CMF, nor Drupal routing, nor Silex is relying on the tree stuff. So they should also still work. cc @fabpot @Crell @dbu One more thing: RouteCollection wasn't an appropriate name for a tree anyway as a collection of routes (that it now is) is definitely not a tree. Yet another point: The XML declaration of routes uses the `<import>` element, which is excatly what the new implementation of addCollection without the need of a tree does. So this is now also more analogous. --------------------------------------------------------------------------- by Koc at 2012-11-26T17:34:15Z What benefit of this? --------------------------------------------------------------------------- by Tobion at 2012-11-26T17:56:53Z @Koc Why did you not simply wait for the description? ^^ --------------------------------------------------------------------------- by dbu at 2012-11-26T18:33:09Z i love PR that remove more code than they add whithout removing functionality. --------------------------------------------------------------------------- by Crell at 2012-11-26T18:49:52Z There's an issue somewhere in Drupal where we're trying to use addCollection() as a shorthand for iterating over one collection and calling add() on the other for each item. We can't do that, however, because the subcollections are not flattened properly when reading back and our current dumper can't cope with that. So this change would not harm Drupal at all, and would mean I don't have fix a bug in our dumper. :-) I cannot speak for any other projects, of course. --------------------------------------------------------------------------- by Tobion at 2012-11-27T19:06:34Z Ok, this is ready.
I've used tree structrure of routes for organizing menu. Now I can't. Very awful BC. |
@Strate There is a KnpMenuBundle if you need menus. It also handles the breadcrumbs... |
@Strate If you were accessing the RouteCollection at runtime, you were breaking all optimizations of the cached router (as getting the RouteCollection triggers the loading of routes from the config files) |
BC break: yes (see below)
Deprecations: RouteCollection::getParent(); RouteCollection::getRoot()
tests pass: yes
The reason for this is so quite simple. The RouteCollection has been designed as a tree structure, but it cannot at all be used as one. There is no getter for a sub-collection at all. So you cannot access a sub-collection after you added it to the tree with
addCollection(new RouteCollection())
. In contrast to the form component, e.g.$form->get('child')->get('grandchild')
.So you can see the RouteCollection cannot be used as a tree and it should not, as the same can be achieved with a flat array!
Using a flat array removes all the need for recursive traversal and makes the code much faster, much lighter, less memory (big problem in CMS with many routes) and less error-prone.
BC break: there is only a BC break if somebody used the PHP API for defining RouteCollection and also added a Route to a collection after it has been added to another collection.
So
must be updated to the following (otherwise the 'foo' Route is not imported to the rootCollection)
Also one must call addCollection from the bottom to the top. So the correct sequence is the following (and not the reverse)
Remeber, this is only needed when using PHP for defining routes and calling methods in a special order. There is no change required when using XML or YAML for definitions. Also, I'm pretty sure that neither the CMF, nor Drupal routing, nor Silex is relying on the tree stuff. So they should also still work.
cc @fabpot @Crell @dbu
One more thing: RouteCollection wasn't an appropriate name for a tree anyway as a collection of routes (that it now is) is definitely not a tree.
Yet another point: The XML declaration of routes uses the
<import>
element, which is excatly what the new implementation of addCollection without the need of a tree does. So this is now also more analogous.