Problem/Motivation
The RouteBuilderInterface has no docbloc and its method docblocks are inaccurate.
Proposed resolution
Add a docblock explaining what the interface does, and including some detail on what route rebuilding and "dumping" actually is.
User interface changes
None.
API changes
None.
Data model changes
None.
Original report by @chx
RouteBuilderInterface does not have a documentation block. It should.
| Comment | File | Size | Author |
|---|---|---|---|
| #35 | interdiff-33-35.txt | 559 bytes | Anonymous (not verified) |
| #35 | routebuilderinterface-2533220-35.patch | 1.54 KB | Anonymous (not verified) |
| #33 | routebuilderinterface-2533220-33.patch | 1.54 KB | Anonymous (not verified) |
| #33 | interdiff-26-33.txt | 1.58 KB | Anonymous (not verified) |
| #26 | 2533220-26.patch | 568 bytes | snehi |
Comments
Comment #1
dawehnerWhat about adding a @see to the Route provider and MatcherDumperInterface
Comment #2
chx commentedI certainly can. But what about an @ingroup menu on those too instead?
Comment #3
dawehnerI like the @ingroup menu but the RouteBuilder <-> RouterProvider are sort of always together, they support each other.
Comment #4
Crell commentedRoutes are deliberately not part of the menu system anymore, so I don't think @ingroup menu is correct. Do we have a routing @group? If not, we should. :-)
The dumper and matcher come as a matched set, but the RouteBuilder itself shouldn't need to be swapped out for a new matcher/dumper set (eg, a Mongo or Cassandra backend).
I would suggest a description here of just "Rebuilds compiled routing information", with an @ingroup of "routing".
Thanks chx for the catch.
Comment #5
chx commentedIf you visit https://api.drupal.org/api/drupal/8 and click "Routing, page controllers, and menu entries" then you land on https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21me...
So while the name "menu" might not be super correct any more, routing is already under group menu.
We can start a routing group for sure but what would it contain that the above one does not?
Comment #6
dawehnerCan you somehow have nested groups?
Comment #7
chx commentedI do not think that feature is supported by the doxygen standard we copied or the api module or ... anything :)
Comment #8
dawehnerWell, then let's start with @ingroup menu, its the right thing to do now.
Comment #9
Crell commentedThen we should start a new @group for routing specifically. Whether we do that as part of this patch or file a follow-up to reorganize it in the next patch, I defer to the committers on. As long as the follow-up is actually filed I am OK either way.
Comment #10
jhodgdonWe can now revive this... On another issue, Menu and Routing topics were split up. See
https://api.drupal.org/api/drupal/8
Use @ingroup routing now instead of @ingroup menu, which will add it to the new split Routing topic:
https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Routing!routing.a...
Comment #11
tim.plunkettComment #12
jhodgdonOK. What we need is for someone to take the patch from above and change @ingroup menu to @ingroup routing. Good Novice task...
Updating issue summary to match the patch/title.
Comment #13
snehi commentedComment #14
snehi commentedComment #15
dawehnerMaybe an @see to MatcherDumperInterface and RouteProviderInterface could be helpful.
Comment #16
jhodgdonSounds like a good idea. Note that in docs headers, when referring to a class include the full namespace.
Comment #17
snehi commentedLittle busy, Anyone else can pick up.
Comment #18
mirom commentedComment #19
mirom commentedAdded @see to MatcherDumperInterface and RouteProviderInterface.
Comment #20
mirom commentedComment #22
mirom commentedReexported patch
Comment #23
Crell commentedOK, let's do it.
Comment #24
cilefen commentedComment #25
alexpottRebuilds the route info and dumps to dumper.is the documentation on the rebuild method - does that need adjusting too? Also I'd have thought some description about what building routes means would be appropriate - or pointing to some documentation that does this.Comment #26
snehi commentedAttaching patch as no activity for a longer time.
Comment #27
mirom commentedComment #28
jhodgdonHm. Neither of those interfaces gives me any indication of what "rebuilding" or "dumping" means, actually. So I think this needs some more work.
Comment #29
snehi commentedComment #30
snehi commentedCan you give hint what should be there.
Comment #31
jhodgdonI really don't know what this interface, or the classes that implement it do. But the doc block in this patch just says:
So it just says it "rebuilds" the route info and "dumps" it to the Dumper. I kind of know what "rebuilds" means, but it would help if the interface told me that. I don't know at all what "dumps" means, so it would be very helpful if it told me what that was.
All I have, instead, is two @see references. If I look at the docs for these two interfaces, all the extremely non-helpful information I get is:
a)
b)
This tells me absolutely nothing about what "rebuilding" or "dumping" is. Not helpful at all. So... this either needs to link me to some docs that explain what these two terms are, or explain them. And since I personally do not know what they mean exactly, sorry, I cannot help you... but those two interfaces are extensions of Symfony interfaces, and although Symfony has nearly zero API docs in their docs header, they do have quite a bit on their project site, so you might be able to learn more there or find a link that could be put into an @see, something like:
or better yet, a paragraph something like:
Comment #33
Anonymous (not verified) commentedWhile the Symfony reference is quite extensive, it doesn't really explain what a "MatcherDumper" is or how it works. Or at least, I couldn't find it.
Looking through the code, I think "dumping" is a somewhat strange name. Symfony uses it to auto-generate PHP code or Apache rules. We use it to fill in the router table. I don't know whether or not we use it for something else as well.
This is not correct. The route info gets added to the dumper, which then can dump it.
I found this to be somewhat ambiguous. Do we always rebuild the route info and only dump it when necessary? Actually no. The necessary part of that phrase refers to both the rebuilding and the dumping.
Attached is a first go at a patch. I wasn't sure whether or not this info should go on the interface, or specifically on the rebuild() method.
The information that our use case is filling the router table is on \Drupal\Core\Routing\MatcherDumper. I would think that is the right place to do so, but we might want to point at it?
Comment #34
jhodgdonThanks! This looks really excellent.
Except for one line:
In your comment that came with the patch, you said that the "only if necessary" phrase applied to the rebuild. So, this line still seems wrong/ambiguous? Maybe it should say "Rebuilds the route information if necessary, and dumps it."?
Comment #35
Anonymous (not verified) commentedRe #34: I really struggled making that a one liner :). Thanks for the suggestion!
I filled out the template for the IS to be a bit more specific on the improvements we are making.
Attached is a new patch, fixing the feedback in #34.
Comment #36
jhodgdonLooks good to me. Thanks for the research and patches!
Comment #37
alexpottCommitted 57a5e9a and pushed to 8.1.x and 8.2.x. Thanks!
Comment #40
dawehnerYeah!