Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suppory hyphen as a delimiter for named parameters in routes? #143

Closed
bnolan opened this issue Dec 14, 2010 · 5 comments
Closed

Suppory hyphen as a delimiter for named parameters in routes? #143

bnolan opened this issue Dec 14, 2010 · 5 comments

Comments

@bnolan
Copy link

bnolan commented Dec 14, 2010

Currently named parameters in routes only stop globbing when a / is encountered. I personally use a hyphen as a delimiter in routes, since I use jquery mobile and it expects to find a dom element with the same id as the current location.hash.

This is a bit of a peculiar case and maybe I'll just have to hack up jquery mobile to work with slash-style routes, but I though I'd open this ticket and see what the regular expression for namedParam should be.

Current regexp:

"([^\/]*)"

My personal branch:

"([^\/-]*)"

Thoughts?

@dvv
Copy link
Contributor

dvv commented Dec 14, 2010

"([^\/\?]*)", to honor possible querystring. Moreover, there should be syntax to denote optional named parameter. Splats (*param) are way greedy. I'd vote for :param?

Querystring is special -- it should be passed intact to handlers, be completely optional and should not accidentally clash with other routes -- I mean a certain route should match URI both with and w/o querystring

--Vladimir

@dvv
Copy link
Contributor

dvv commented Dec 15, 2010

We should also escape any literal char in routes. That way we could catch special chars as ?/[]().

I mean e.g. :entity/:id?*query --> /([^\/]*)\/([^\/]*)\?(.*)?/ , notice the first ? is autoescaped. Otherwise being treated as vanilla char it breaks assumptions on :id token

@jashkenas
Copy link
Owner

I patched, and started to test this issue, before realizing that the premise is funky. The only part of the URL that we're dealing with here is the post-hash part. Query strings have nothing to do with it, and you probably shouldn't be encoding faux query strings into your location hash in the first place.

As to bnolan's proposal to delimit on dashes, I'm afraid that dashes are very valid characters in URLs, and are often parts of the literal named param: In our case, slugs for Accounts and Documents have plenty of dashes in them.

So, closing the ticket as a wontfix.

@dvv
Copy link
Contributor

dvv commented Dec 17, 2010

We should escape any literal char in routes. What's after-hash is the URL the browser takes. If we want a single page app, aheter-hash is the only route.

Why don't you escape p in "search/:query/p:page" example at http://documentcloud.github.com/backbone/#Controller-extend? just because p is not treated as special regexp char. No? Consider p be ?

--Vladimir

@jashkenas
Copy link
Owner

dvv: Thanks for raising the issue. Here's a patch for escaping regex characters in literal route parts:

SHA: 3098321

Give it a try and let me know what you think.

jasonwebster pushed a commit to jasonwebster/backbone that referenced this issue May 13, 2011
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants