Splat support in routes

[gitblit]

I'm not a Ruby guy, I'm a Java guy. I have no experience with Sinatra, but I see that Sinatra supports extracting wildcard values from the url as a splat array. That would be a fantastic addition (for me) to your Spark framework. I currently struggle with other frameworks' limitations in handling routing and url encoded paths correctly. Especially when combined with servlet containers that are openly hostile to url encoded paths (I'm talking about you, Tomcat).

I want to be able to match a route and extract a path subset from a url like the following:
/:project:/repo/tree/:ref/*

I was pleased to discover, after experimenting, that you can mix variables and static paths, as in the above example, in Spark - that wasn't immediately obvious from the unit tests nor the samples.

So, in short, being able to easily grab splat[0], splat[1], etc would be tremendous!
I hope it is on your roadmap.

Thanks for your consideration.

[perwendel]

Looking at the implementation of the route matching (which I developed two years ago and hence don't remember to well :-S) it seems like Spark only support wildcards placed in the end of the path i.e. /domain/* and not //something//hello. This would have to be fixed before considering supporting splat.

[gitblit]

Yup, it does match match trailing wildcard urls, which is sufficient for my current need. But there is no way to extract just the wildcard match from the url without having to manually dissect it. At least it looks that way to me.

[perwendel]

I just developed and pushed splat functionality to the repo.
Splat parameters can now be obtained by the String[] splat() method in Request.
Hope you find this useful!

[gitblit]

Thanks, Per. That is a welcome improvement.

[robosoul]

Hi guys,

I know I'm 3 years late :) but just wanted to ask if someone could explain the benefits of using splat over params method? For example:

    get("/say/:what/to/:name", (request, response) ->
            request.params(":what") + " " + request.params(":name"));

    get("/sing/*/to/*", (request, response) ->
            request.splat()[0] + " " + request.splat()[1]);

both routes will yield with the same result, but (for me) the first method is more readable (+ no ArrayIndexOutBoundsException danger).

Thank you,
Luka

[gitblit]

Hmm. Reaching back.....

IIRC the difference came down to named parameters did not supported nested / characters.

So for example, /say/good/golly/miss/molly/to/luka request.splat()[0] would be good/golly/miss/molly and I think (at the time anyway) the named parameters approach would not allow you to grab slash-containing values.

[robosoul]

Awesome. That makes perfect sense. Thank you very much.