Updated: Comment #N
Problem/Motivation
One of the drawbacks of no longer providing URL paths for generating links, but route names, is that we can link to less URLs than we could before, as a lot of routes need parameter replacement values if links are to be made of them. One example of this is #2147689: [regression] Support route parameters for *info.yml files' "configure" route name. Another one is base_route_name
in *.config_translation.yml
files. This effectively is a regression since Drupal 7.
Proposed resolution
Whenever a link is generated based on a route, there must be the possibility to provide values for route parameters.
Remaining tasks
Decide on this policy.
User interface changes
None.
API changes
None. The policy enforces non-BC-breaking API additions only.
Comments
Comment #1
Crell CreditAttribution: Crell commentedAt first blush this seems reasonable. In order to link to a route, you need to be able to provide its parameters. Where you used to have a path, you now need a route/parameters.
Comment #2
XanoOne concern that was raised by timplunkett is that we cannot provide dynamic parameter values. Within the context of a statically defined route name (just we defined static URL paths in Drupal 7) this is true. This is, however, no regression. Example: just like
*.info
files in D7 provided aconfigure
route path with the (static) placeholder values filled in, in D8 that value would be a route name, with an additional array of static route parameters. Instead of entering them into the URL directly, we provide a map, but the values in questions have been and will remain static, as long as the context is static as well.Comment #3
XanoThis hasn't manifested itself as a regression in Drupal core (yet), but it has in contrib.
Comment #4
dawehnerCan someone explain here the actual "regression"?
Comment #5
XanoThe regression is that if route parameters are unsupported, we can no longer link to URL paths with placeholders/wildcards/parameters.
Comment #6
tim.plunkettThe configure link has its own issue. The config_translation does not, AFAIK.
Comment #7
XanoDo you mean #2154743: Support route parameters for *.config_translation.yml files' base_route_name properties?
Comment #8
tim.plunkettYes. The config_translation routing code has many many more problems than just that, I will be opening a critical in the morning when I can think straight.
Comment #9
XanoRegardless of any Configuration Translation issues, what are your thoughts on this issue in general?
Comment #10
tim.plunkettI think that each are a case-by-case basis, and no policy needs to exist.
In 90% of places in core they are a pair.
Comment #11
XanoCan I ask why you think this does not to be done everywhere? The way I see it, anything that needs to do something with a route has no right to impose any limitations on that route.
Comment #12
XanoBump.
Comment #13
dawehnerYes, we should make it possible in most places. for the rare edge case we can always tell people that they can also generate routes with different default values.
Comment #14
dawehnerWith the appearance of the url object we have fixed this issue. It bundles the information together and we are fine.