Open Thinkscape opened 8 years ago
There is no catch-all route supplied by default (although in the new architecture, catch-all would be implemented as a path parser, not as an entire route). Hostname and scheme matching are handled by the generic route, see the README. And so far nobody could show me a valid example anymore where the segment parser couldn't handle anything a pure regex parser could.
The syntax is somewhat simpler, but confusing :-\ I've now searched through readme, and yeah, I see there are a few "hidden" keys you can use to get some behavior... in addition to the [0], [1], [2] keys.
valid example anymore where the segment parser couldn't handle anything a pure regex parser could
really ? I use regex routes all the time ...
'regex' => '#download-file/id-(?<id>[0-9]+)/(?<filename>.*?)#'
Doesn't seem like you need a regex at all:
'download-file/id-:id/:filename'
(with the constraints defined properly).
Although I'm thinking about integrating the constraints directly into the route pattern like some other routers do.
Nope, because your route does not do catchall of the filename... and there's no way to do backtracking, alternatives, lookahead/behinds etc. Also - can't control greediness or utf8 handling, or case sensitivity ...
Sure it can do catch-all of the filename, simply define it's constraint to be .*?
. The constraint can also contain alternatives and such. And again, the rare cases where a segment route can't handle something, you can always use another path parser.
you can always use another path parser
Like ... Regex parser? :dash:
Yes, for instance. Although I'm not supplying one by default.
Why not? That's another step back :\
https://github.com/zendframework/zend-mvc/tree/master/src/Router/Http
Just hoping you have that thought out, as it might screw up your current architecture. There's tons of use-cases where those route types are required.