Make route hashes slash-insensitive.

[spikensbror]

Not really sure if this is an issue or should be considered as a feature request, but I stumbled upon this issue while working around with sammy for a bit.

Basically, routes currently work like this:

(route hash) op (browser hash)
#/test/:name != #/test/something/
#/test/:name == #/test/something

Meaning if the route would be specified without a trailing slash, it would not trigger if the URL would contain a trailing slash. This stumped me for a while really and I have no idea if this was intentional or not but I think it would be much better if sammy could react "slash-insensitively".

[dvdotsenko]

In the world of regular URLs "..something/" and "something" are very different. One points to folder. The other to file in a parent folder.These are distinctly not the same. Bewildered by assertion that they are.

Still, if such behavior is desired, you could just regex.

var a = "#/test/something"
, r = /\#\/test\/([^\/]+)\/*$/

a.match(r)
// ["#/test/something", "something"]

(a + '/').match(r)
// ["#/test/something/", "something"]

[trans]

Even if not the same, it would be nice if there was very easy way to specify they should be treated the same. e.g

#/test/:name/?

That probably won't suffice, but you get the idea.

[endor]

One way to do this is:

this.get('#/test/:name', callback);
this.get('#/test/:name/', callback);

Another way is:

this.get(/\#\/test\/(.+)\/?/, function() {
  // evaluate this.params.splat;
});

[trans]

Can/could the methods take options? Then something like:

this.get('#/test/:name', :trail=>true) do
  ...
end

That would be a nice way.

@endor Your first alternative is ok. That's definitely how I would handle it now, when need be. The regex approach though, I find it mind-numbing to have to look at perly code like that.

[endor]

Sure it could (though not ruby hashes ;)), but the question is, is this something a lot of users want or is it rather a special case. If it is the latter - why make the code more confusing than it needs to be? I mean we did say that those are two different routes after all, didn't we? Anyway.. to close this up, I would suggest we leave it as it is for now, and if other people come around who want something like this, we might add it. If you're into it, it would be great if you could fork sammy and implement that yourself (with tests), so we can just merge it in, if it happens to be attractive to other users. Thanks for the suggestion.. it does look a lot better than the regexp approach :)