Params can't have dots (.) on the keys

[rickitan]

Hi,

I've been working with ui-router for awhile and I'm currently experiencing problems with the parameters of a state.

Here's the state declaration:

.state('home', {
parent: 'auth',
url: '/?tags.network&tags.teams',
reloadOnSearch: false,
views: {'@root': { templateUrl: '/views/partials/series/index.html', controller: 'LandingCtrl' }}
})

As you can see I want the parameters to be called 'tags.network' and 'tags.teams', ui-router is throwing the following error:

Duplicate parameter name 'tags' in pattern '/?tags.network&tags.teams'.

To inspect further I dropped some breakpoints and noticed that ui-router splits the strings by the dot and therefore creates 4 parameters tags, network, tags and teams (this fails because tags is repeated).

I then change the URL to: '/?tags.network', doing $state.go('home', {'tags.network':'AMC'}) changes the state but the parameter is not present. Since I know ui-router is splitting by the dot, I tried the following: $state.go('home', {'network':'AMC'}) and it worked.

Has anyone experienced this ? What can be done ? Is it illegal to have dots in the params keys ?

Thanks,

-Ricardo.

[nateabele]

There was a separate PR on this that decomposed dot-separated keys into nested objects, which seemed too complicated to me.

I'm fine with changing the regex match to allow keys with dots, and if people want behavior more complex than that, they can extend UrlMatcher. @christopherthielen Thoughts?

[christopherthielen]

I'm also fine with allowing dots in parameter names. why were we splitting on '.' I wonder...?

[nateabele]

I don't think we were splitting on it, I think the key-match regex just didn't recognize it as valid.

[jpeffer]

Spring MVC / REST allows for request parameters to be mapped directly into complex object DTOs, using dot notation to access nested objects. Being able to support this would most likely benefit anyone consuming a Spring IO based web-service.

[idpaterson]

I started working on this by converting the inclusive rules that match parameter names to exclusive. Trying to define all the possible characters that are valid is not a good situation to be in and the set provided by ui-router is very minimal. In my case we needed both . and $, and a pull request adding those two characters to the list of supported param characters would be silly. Based on URL and ui-router placeholder syntax, I believe that only the following characters need to be excluded from parameter names: ? & ; # = : { } \ /

However, there is a backup test that throws exceptions like Invalid parameter name 'addresses.city' in pattern '/users/?from&to&addresses.city'. It seems to mostly ensure that snake case names do not begin or end with a - and that parameters including [ and ] have them only immediately at the end of the parameter name foo[]. Is it url-router's responsibility to police parameter names? I understand the convenience of accessing parameters with dot syntax but a convenience should not be a requirement.

The only way to proceed with this change is to remove that validation, I don't think it serves a significant purpose. There is some related discussion in #337 regarding support for any application/x-www-form-urlencoded query string. We're a bit removed from that due to the { } : characters reserved by ui-router, but exclusive rather than inclusive matching is the right direction in my opinion.

Parameter name matching would be based on the exclusive [^?&#=:{}\\\/]+ rather than the current inclusive [\w\[\]-]+.

[jpeffer]

An exclusive approach makes perfect sense in this case, rather than trying to define a list of allowable patterns. Any idea when this might be possible? I have not seen too much movement on the 0.2.16 milestone.

[nateabele]

Any idea when this might be possible? I have not seen too much movement on the 0.2.16 milestone.

Our main push right now is to get a dev preview of 1.0 out the door, and it has been a huge job, so a lot of smaller things like this has kind of been pushed to the wayside, but as a relatively isolated piece of work, I think it's a great opportunity for a community member to pick up the torch and develop a proof of concept.

The larger concern for me isn't the matching regex so much as (a) the implications of object keys with special characters in other parts of the system and (b) the complexities of handling the special cases people have requested (i.e. using dot-separated keys to represent nested objects), which I'm not too enthused about.

What'd be great to see is (as an example) providing a simple way to extend URLMatcher in user-land to support use cases like that.

[christopherthielen]

Looks like this got resolved in d31b333