Splat pollution of params' space
Hello dancers! I like Dancer but I'm having a little problem with this regex/wildcard matching. The issue is that hash returned by params() in the relevant sub always contains 'splat' key referring to array of matches. Maybe this reference might be useful (when?), what if I *really* want to pass "splat=splosh"? According to my testing, the value is lost! Can this behavior be disabled? Or is it a bug? (IIUC, I can always do `[ splat ]` so why the pollution?) For illustration, request is: GET /there?splat=splosh&bar=baz and relevant route: get qr{(.*)} => sub { my $params = params(); my ($path) = splat; # '/there' my $foo = $params->{foo}; # 'bar' my $splat = $params->{splat}; # [ '/path' ] instead # of 'splosh'! my $splat = param('splat'); # '/there' } Thanks, aL. -- Alois Mahdal
Hi, I think this is due to this line : https://github.com/PerlDancer/Dancer/blob/devel/lib/Dancer/Route.pm#L139 And I don't know the rational for this feature. I don't think we need to pollute the request params with splat, so I vote for its removal. Of course in theory it breaks backward compatibility, so caution must be applied... Anyone ever used $params->{splat} ? I think the splat() function can be used instead in every cases. On 26 December 2012 21:33, <alois.mahdal.1-ndmail@zxcvb.cz> wrote:
Hello dancers!
I like Dancer but I'm having a little problem with this regex/wildcard matching. The issue is that hash returned by params() in the relevant sub always contains 'splat' key referring to array of matches.
Maybe this reference might be useful (when?), what if I *really* want to pass "splat=splosh"? According to my testing, the value is lost!
Can this behavior be disabled?
Or is it a bug? (IIUC, I can always do `[ splat ]` so why the pollution?)
For illustration, request is:
GET /there?splat=splosh&bar=baz
and relevant route:
get qr{(.*)} => sub { my $params = params(); my ($path) = splat; # '/there' my $foo = $params->{foo}; # 'bar' my $splat = $params->{splat}; # [ '/path' ] instead # of 'splosh'! my $splat = param('splat'); # '/there' }
Thanks, aL.
-- Alois Mahdal ______________________________**_________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
Hi, Maybe for compatibility (-ish), it could be changed so that 'splat' is still stored in the request params, but only if there is not an existing 'splat' param. This would fix the ?splat=spolsh case, and more than likely cover any existing users of params->{splat} as splat()? Haven't dug into the code so not sure what technical effort that implementation would require. -- Rik Brown http://www.rikbrown.co.uk On Wednesday, 26 December 2012 at 21:31, damien krotkine wrote:
Hi,
I think this is due to this line :
https://github.com/PerlDancer/Dancer/blob/devel/lib/Dancer/Route.pm#L139
And I don't know the rational for this feature. I don't think we need to pollute the request params with splat, so I vote for its removal. Of course in theory it breaks backward compatibility, so caution must be applied... Anyone ever used $params->{splat} ? I think the splat() function can be used instead in every cases.
On 26 December 2012 21:33, <alois.mahdal.1-ndmail@zxcvb.cz (mailto:alois.mahdal.1-ndmail@zxcvb.cz)> wrote:
Hello dancers!
I like Dancer but I'm having a little problem with this regex/wildcard matching. The issue is that hash returned by params() in the relevant sub always contains 'splat' key referring to array of matches.
Maybe this reference might be useful (when?), what if I *really* want to pass "splat=splosh"? According to my testing, the value is lost!
Can this behavior be disabled?
Or is it a bug? (IIUC, I can always do `[ splat ]` so why the pollution?)
For illustration, request is:
GET /there?splat=splosh&bar=baz
and relevant route:
get qr{(.*)} => sub { my $params = params(); my ($path) = splat; # '/there' my $foo = $params->{foo}; # 'bar' my $splat = $params->{splat}; # [ '/path' ] instead # of 'splosh'! my $splat = param('splat'); # '/there' }
Thanks, aL.
-- Alois Mahdal _______________________________________________ dancer-users mailing list dancer-users@dancer.pm (mailto:dancer-users@dancer.pm) http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm (mailto:dancer-users@dancer.pm) http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Thu, 27 Dec 2012 02:58:29 +0000 Rik Brown <rik@rikbrown.co.uk> wrote:
Hi,
Maybe for compatibility (-ish), it could be changed so that 'splat' is still stored in the request params, but only if there is not an existing 'splat' param. This would fix the ?splat=spolsh case, and more than likely cover any existing users of params->{splat} as splat()?
I'd rather suggest removing the assignment at all. Mixing route matching mechanism with user data does not seem as good practice to me at all. Plus, this case would still be broken anyway: get qr{(.*)} => sub { my $params = params(); return ( "Hello, you have specified following parameters: " . join ", ", keys %$params ); }; i.e. it would *never* return empty list (unless "treated" with some ugly and very Dancer-specific code). Provided that the "feature" is not documented (I haven't found it anywhere), I wouldn't see it as a big deal to get rid of it (with proper alignment with release cycle, of course). (Even if there were people out there who use splat like this, and started to complain, we could give them a big warm "Welcome To The World Of Undefined Behavior(tm)" :-D) Thanks, aL. -- Alois Mahdal
participants (4)
-
Alois Mahdal -
alois.mahdal.1-ndmail＠zxcvb.cz
-
damien krotkine -
Rik Brown