parsing query params after optional rest path

[Standa666]

I have following query

one/two/three/four?id=1&test=1

and router based on string

one/two/:path*::?query:

I expect two values

0. "three/four"
1. {id: 1, test: 1}

but I receive

0. "three/four?id=1&test=1"
1. undefined

I found that compiled pattern looks like this (example)

/^/?one/two/?(.*)?/?(?:?([^#]*))?/?$/i

but it should probably looks like this (examle)

^/?one/two/?([^?]*)?/?(?:?([^#]*))?/?$

The generated pattern for :path*: covers also query which starts with question mark. So this character should probably be excluded.

Am I right?

[millermedeiros]

rest segments match anything. you only have the conflict because both segments are optional and we don't have any special logic for this case.

[olavorn]

Same for me, i'm in a similar case strugling with the parser to route:

Path:
"Route/App#container1=/Account/Dashboard&id=1"

Expression:
"Route/App#container1=/{controller}/{action}:&id={id}:"

Expected:
controller => Account
action => Dashboard
id => 1

Result:
controller => Account
action => Dashboard&id=1
id => null

how can we contribute to fixing it with a right aproach?

[millermedeiros]

@olavorn your expression should really be Route/App#container1=/{controller}/{action}:?query: - :&id={id}: is not a valid segment. and change the path to "Route/App#container1=/Account/Dashboard?id=1"

another option is to use the rest segment ({action*}) and parse the ID by yourself and/or use the route.rules.normalize_

[olavorn]

Hi @millermedeiros!!

as I stated, I understand the workarounds, but, as I'm using Ben Alman's jQuery BBQ (which is also awesome) to manage the hash variables. the &id part is not about the url itself, but is a separate variable. see:

"Route/App#container1=/Account/Dashboard&id=1" is built as
$.bbq.pushState({ container1 : '/Account/Dashboard', id: 1 } )

$.bbq.getState('container1') //returns "/Account/Dashboard"
$.bbq.getState('id') //returns 1

Agreed that '/Account/Dashboard&id=1' is not valid as url, but that is not the case, as you can see. They are diferent variables within hash section and there is no reason the parser should not understand that as so.

[rg1]

I'm hit with the same problem. The solution I found is to change the match for the OR (and RR) token from greedy to non-greedy. Do you understand what I mean or should I submit a pull request?

[Yogeshberia]

Also, in the first case, if the optional "path" parameter doesn't have a rest segment and is omitted, the query param can't be used without using a preceding slash (/).

Doesn't Work: one/two?id=1&test=1
Works: one/two/?id=1&test=1