Genie.jl

Genie.jl copied to clipboard

In some cases, it is convenient to have a mechanism for processing parts of a path. E.g. I want to have a hierarchical processing of the path endingphotos/*other. This route would match photos/12 or /photos/long/path/to/12, setting other-segment to "12" or "long/path/to/12".

This way may be used for organizing access to a file storage with additional control functions.

See more examples: https://guides.rubyonrails.org/routing.html#route-globbing-and-wildcard-segments

As mentioned in https://github.com/GenieFramework/Genie.jl/issues/661 in Genie 6 (currently in the v6 branch) we have some support for this. It's not extensive as Rails' as it's greedy. So for now we only process routes like /foo/bar/* that would match /foo/bar/x, or /foo/bar/x/z etc.

The matching part ends up in params["_"] as x or x/z.

If you want to help with this for ex by extending it to match better (less greedy) and/or backport it to Genie 5, happy to help.

Thanks, this is really good that you implemented this function. At the same time, RoR is still a good sample of how to organize dynamic components of the path. The cases 'books/*section/:title' or '*a/foo/*b' are also sometimes useful. E.g. for the 'books/*section/:title'I can manage a hierarchical taxonomy of sections and request the book by title. In case of '*a/foo/*b' the a can encode the API version, but b be a name of the resource. But no way to have more than one wildcard segment when using '_' variables.

BTW, have you thought about replacing of the for r in routes() with multiple regex checks by a single state machine implemented with something like Automa.jl to avoid performance problems in applications with many paths?

@rssdev10 I have not thought about replacing the routes lookup and your suggestion is very interesting. I'll look into it, thanks.