Needs work
Project:
Drupal core
Version:
main
Component:
routing system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
17 Jan 2015 at 14:38 UTC
Updated:
13 Jul 2022 at 23:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
znerol commentedA desperately ugly first attempt.
Comment #3
znerol commentedComment #4
znerol commentedComment #5
dawehnerInteresting
Comment #6
neclimdulThat's really cool. The documentation was a bit lacking on technical details so I dug into some code and updated the summary with what I found. Haven't looked too much into the patch but so far, big +1.
Comment #7
znerol commentedThe current patch is not more than a hack in order to estimate the work needed to fix the Drupal specific extensions of the compiled route (
pattern outline,fitandnum parts). Symfony understands even more separators RouteCompiler::SEPARATORS. But it is probably not necessary/desirable to support them all in Drupal?Comment #8
znerol commentedIt seems to me that generating the pattern outline, fit and num parts would be much easier by just examining the tokens produced by the upstream route compiler. This would make Drupal automatically compatible to the whole Symfony route pattern syntax. Note however, that it would be necessary to adapt the outline candidate generator in
RouteProvideralso.I've inlined all the code because other parts of Drupal seem to depend on the pulbic methods exposed by the Drupal
RouteCompiler.Comment #9
znerol commentedThat is not as easy as it seems though. The Symfony route compiler generates a single token for a continuous path without any placeholders in between. E.g.
/node/add/{node_type]only generates two tokens (num_parts = 2, fit = 2), while HEAD generates num_parts = 3, fit = 6.Comment #10
Crell commentedThe "Fit" algorithm was ported forward from Drupal 7 essentially unchanged, because it worked. I believe it's specific to the SQL implementation, though. I'm fine with expanding the definition of what we consider a valid path pattern, but we have to be mindful that it needs to be implementable in SQL, MongoDB, raw PHP, and whatever other implementations we want to support.
Comment #12
znerol commentedThat's not correct. The resulting SQL is very simple and portable to any decent database:
The pattern outline is essentially a secondary index. It is used to reduce the set of routes to be loaded prior to actually matching the incoming path against the route collection. Efficiency of this approach could be measured by tracking false positives, i.e. routes loaded from the db but later rejected by the regex.
That said, the obvious way to make the extension syntax work is simply to ignore file extensions altogether when generating the pattern outline and pattern outline candidates respectively. The attached patch implements this, no interdiff because this is yet another experiment.
Comment #14
Crell commentedOr what if for outline purposes we treated the format as part of the pattern? Ie, replaced . with / before calculating the outline and fit?
And by SQL-specific, I mean non-SQL implementations may have something much better they can use. Eg, some SQL backends support regex matching in the query itself; that may or may not be faster on some engines. MongoDB probably has something similar although I'm not sure off hand. Someone was working on a Redis(!) backend for the Router, although how that even works I don't know... :-)
Comment #18
dawehnerAre we sure we really want to support that?
Comment #24
longwaveFound via the Bug Smash Initiative random issue triage.
There hasn't been any interest or movement on this for some years, and we don't claim to support everything Symfony does, so reclassifying as a task.
Comment #27
larowlanJust stumbled upon this in a client project, thought I was going nuts. Dug down into the router until I found the source of the issue. Then find someone has been down this route before 🥁