request for feature
unless default params already exist, the following would make life a lot easier get '/foo/:foo_id?/bar/:bar_id?' => sub { my $foo_id = params->{'foo_id'} || <default foo value>; my $bar_id = params->{'bar_id'} || <default bar value>; }; Many thanks, -- Puneet Kishor
I don't follow On Mon, Jan 17, 2011 at 9:03 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
unless default params already exist, the following would make life a lot easier
get '/foo/:foo_id?/bar/:bar_id?' => sub { my $foo_id = params->{'foo_id'} || <default foo value>; my $bar_id = params->{'bar_id'} || <default bar value>; };
Many thanks,
-- Puneet Kishor _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
I think that Puneet is suggesting to have a syntax for non-mandatory parts in the route specifier, i.e. the foo_id might be there, as in: /foo/1/bar/30 or not, as in /foo/bar/30 in which case a default value for foo_id can be set inside the route handler. Trying to guess a possible regex for it (don't know if "\w" is correct here): /foo(?:/(?<foo_id>:\w+))?/bar(?:/(?<bar_id>:\w+)) i.e. each named capture "name" for a parameter is expanded to "(?:/(?<name>:\w+))?" (or whatever is used instead of "\w" today). Cheers, Flavio. On Mon, Jan 17, 2011 at 11:01 PM, sawyer x <xsawyerx@gmail.com> wrote:
I don't follow
On Mon, Jan 17, 2011 at 9:03 PM, Puneet Kishor <punk.kish@gmail.com>wrote:
unless default params already exist, the following would make life a lot easier
get '/foo/:foo_id?/bar/:bar_id?' => sub { my $foo_id = params->{'foo_id'} || <default foo value>; my $bar_id = params->{'bar_id'} || <default bar value>; };
Many thanks,
-- Puneet Kishor _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
... and of course I made mistakes putting too many ":"s... the right expansion would be: /foo(?:/(?<foo_id>\w+))?/bar(?:/(?<bar_id>\w+)) Cheers, Flavio. On Mon, Jan 17, 2011 at 11:13 PM, Flavio Poletti <polettix@gmail.com> wrote:
I think that Puneet is suggesting to have a syntax for non-mandatory parts in the route specifier, i.e. the foo_id might be there, as in:
/foo/1/bar/30
or not, as in
/foo/bar/30
in which case a default value for foo_id can be set inside the route handler. Trying to guess a possible regex for it (don't know if "\w" is correct here):
/foo(?:/(?<foo_id>:\w+))?/bar(?:/(?<bar_id>:\w+))
i.e. each named capture "name" for a parameter is expanded to "(?:/(?<name>:\w+))?" (or whatever is used instead of "\w" today).
Cheers,
Flavio.
On Mon, Jan 17, 2011 at 11:01 PM, sawyer x <xsawyerx@gmail.com> wrote:
I don't follow
On Mon, Jan 17, 2011 at 9:03 PM, Puneet Kishor <punk.kish@gmail.com>wrote:
unless default params already exist, the following would make life a lot easier
get '/foo/:foo_id?/bar/:bar_id?' => sub { my $foo_id = params->{'foo_id'} || <default foo value>; my $bar_id = params->{'bar_id'} || <default bar value>; };
Many thanks,
-- Puneet Kishor _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Monday, January 17, 2011 at 5:13 PM, Flavio Poletti wrote:
I think that Puneet is suggesting to have a syntax for non-mandatory parts in the route specifier, i.e. the foo_id might be there, as in:
/foo/1/bar/30
or not, as in
/foo/bar/30
in which case a default value for foo_id can be set inside the route handler. Trying to guess a possible regex for it (don't know if "\w" is correct here):
/foo(?:/(?<foo_id>:\w+))?/bar(?:/(?<bar_id>:\w+))
i.e. each named capture "name" for a parameter is expanded to "(?:/(?<name>:\w+))?" (or whatever is used instead of "\w" today).
Yeah, kinda. Actually, I gave a wrong-ish example because of more than one params, which makes the capture more difficult requiring the hairy regexp you provided above. But yes, you got the spirit of the question. Consider the more common get '/books' get '/books/:book_id' I need two routes as above. Would be nice to just have one like below that does the job of both get '/books/:book_id?' The above is how it is implemented in CGI::Application, hence my experience with such a capability. Thanks,
Cheers,
Flavio.
On Mon, Jan 17, 2011 at 11:01 PM, sawyer x <xsawyerx@gmail.com> wrote:
I don't follow
On Mon, Jan 17, 2011 at 9:03 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
unless default params already exist, the following would make life a lot easier
get '/foo/:foo_id?/bar/:bar_id?' => sub { my $foo_id = params->{'foo_id'} || <default foo value>; my $bar_id = params->{'bar_id'} || <default bar value>; };
Many thanks,
-- Puneet Kishor _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Apparently Sinatra does have some support for optional settings. The following makes the trailing slash optional: get '/my/route/?' I wonder how it's being done. We can try a weird regex to catch these, but perhaps it should be written as a regex instead in the first place. Sukria, can you verify whether Sinatra are using regex for routes or just have a tricky regex to handle route compilation and optional parameters?
Le 18/01/2011 07:53, sawyer x a écrit :
Sukria, can you verify whether Sinatra are using regex for routes or just have a tricky regex to handle route compilation and optional parameters?
According to the source, Sinatra does the same as we do: building a regexp for every single route: https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1051 But at first glance I don't see where they handle that conditional token... -- Alexis Sukrieh
On Tue, Jan 18, 2011 at 12:38 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
Le 18/01/2011 07:53, sawyer x a écrit :
Sukria, can you verify whether Sinatra are using regex for routes or
just have a tricky regex to handle route compilation and optional parameters?
According to the source, Sinatra does the same as we do: building a regexp for every single route:
https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1051
But at first glance I don't see where they handle that conditional token...
Line 1081?
Le 18/01/2011 11:40, sawyer x a écrit :
But at first glance I don't see where they handle that conditional token...
Line 1081?
Well, I don't think so, let's investigate with irb: I've copied the build method in a dumb class (TestRegexp) in order to play with it, because I don't feel like parsing all that ruby code with my brain ;) First of all a simple case: what does "/test" ends up with: irb(main):002:0> TestRegexp.compile('/test') => [/^\/test$/, []] OK, fair enough, pretty the same at what Dancer builds. Now, what happens with a question mark: irb(main):003:0> TestRegexp.compile('/test?') => [/^\/test?$/, []] Well, nothing more... Must be somewhere else.
Le 18/01/2011 11:47, Alexis Sukrieh a écrit :
Le 18/01/2011 11:40, sawyer x a écrit :
But at first glance I don't see where they handle that conditional token...
Line 1081?
Well, I don't think so, let's investigate with irb:
I've copied the build method in a dumb class (TestRegexp) in order to play with it, because I don't feel like parsing all that ruby code with my brain ;)
First of all a simple case: what does "/test" ends up with:
irb(main):002:0> TestRegexp.compile('/test') => [/^\/test$/, []]
OK, fair enough, pretty the same at what Dancer builds.
Now, what happens with a question mark:
irb(main):003:0> TestRegexp.compile('/test?') => [/^\/test?$/, []]
Well, nothing more...
OK, my bad ;) Here it is: irb(main):004:0> TestRegexp.compile('/test/(:id)?') => [/^\/test\/\(([^\/?#]+)\)?$/, ["id"]] Looks like there is nothing to do actually, the quotation mark is kepts as is and that ends up with a valid regexp, with the capture being optional. Dancer should definitely behave the same (but is not)...
Hi, The patch was pretty easy :) https://github.com/sukria/Dancer/commit/cf67027fd8d77cb649e85980dc6cc4acad28... Will be shipped with the next 1.3 release. for the record, there was an issue reported about that: https://github.com/sukria/Dancer/issues#issue/94 -- Alexis Sukrieh
On 18/01/11 10:28 PM, Alexis Sukrieh wrote:
Hi,
The patch was pretty easy :)
https://github.com/sukria/Dancer/commit/cf67027fd8d77cb649e85980dc6cc4acad28...
Will be shipped with the next 1.3 release.
for the record, there was an issue reported about that: https://github.com/sukria/Dancer/issues#issue/94
Thanks Alexis. This will come in handy. Matt
On Tue, Jan 18, 2011 at 1:28 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
Hi,
The patch was pretty easy :)
https://github.com/sukria/Dancer/commit/cf67027fd8d77cb649e85980dc6cc4acad28...
Will be shipped with the next 1.3 release.
Well done!! Puneet, thanks for raising this issue!
Alexis Sukrieh wrote:
Hi,
The patch was pretty easy :)
https://github.com/sukria/Dancer/commit/cf67027fd8d77cb649e85980dc6cc4acad28...
Will be shipped with the next 1.3 release.
for the record, there was an issue reported about that: https://github.com/sukria/Dancer/issues#issue/94
Heh heh. Turns out the original issue requestor was me. Thanks. -- Puneet Kishor
participants (5)
-
Alexis Sukrieh -
Flavio Poletti -
Matthew Vickers -
Puneet Kishor -
sawyer x