reverse routing

[jdv145]

I'm not an expert on git-etiquette , but i hope this is the right place for a remark/suggestion or 2.

Basically i made a reverse router myself, just using some regexps and string replacements (i love regexp's power, but it doesn't always help to create the easiest to understand code). It worked but felt a bit cumbersome.

I think the routing part of my system is very important, so i gave it a second attempt where i created a full parse-tree and just traveled through it doing as i pleased (checking, var injection, whatever). Afterwards the tree can "rebuild" itself again and it works fine. Also one of the reasons to build a tree is to resolve ambiguity of optional parameters (i previously was not aware of the (very wise) restrictions on optionals, so the tree works for way more then is allowed in fastroute ).

i recently found out there is a suggestion how to reverse routes based on fastroute internals which i of course prefer.

I'm referring to: this

• I was wondering why something like the suggestion is not implemented in fastroute, since it seems to work fine. Where any person is routing, sooner or later an urls needs to be generated.

• Using the linked suggestion as a base for my own implementation, i'm a bit hesitant to blindly trust the output from RouteParser\Std for future versions to come. Any feedback on this? I did look into the parser of course but i only superficially understand its inner workings.

(- just out of curiosity, why not use a parse tree, and work with regexps? Is this bc its more work to code ? )

[nikic]

I was wondering why something like the suggestion is not implemented in fastroute, since it seems to work fine. Where any person is routing, sooner or later an urls needs to be generated.

I agree that it would be nice to include this functionality, the problem for me is that I don't see a good way to integrate it into the current architecture. Among other things a) the dispatcher no longer has the necessary information to do this and b) I think that reverse routing requires support for "named routes" as a prerequisite, something we don't have either.

Suggestions on how to integrate this (API wise) would be welcome.

Using the linked suggestion as a base for my own implementation, i'm a bit hesitant to blindly trust the output from RouteParser\Std for future versions to come. Any feedback on this? I did look into the parser of course but i only superficially understand its inner workings.

This library follows semver, and the parser is part of the public API, so the format is not going to change (at least in 1.x).

(- just out of curiosity, why not use a parse tree, and work with regexps? Is this bc its more work to code ? )

Mainly because at the time the route format was rather simple and a parser seemed like overkill. Maybe that's not the case anymore ^^

[burzum]

@nikic I would like to see named routes as well and reverse routing.

https://github.com/nikic/FastRoute/blob/master/src/Route.php

Wouldn't it be possible to simply add a 5th arg here $name? A reverse route class could simply take the collection and pick a route by it's name and reverse it.

By the way, why is the returned structure unspecified? From what I've seen it's basically always an array and you identify the kind of result by the first key. https://github.com/nikic/FastRoute/blob/master/src/DataGenerator.php

Wouldn't it make sure sense to return an object with an interface? Like RouteNotFoundResult, FoundResult and NotAllowedResult implementing RoutingResultInterface? If you implement array access this could work in a BC fashion without breaking stuff.