- dancer-users - lists.preshweb.co.uk

Re: [Dancer-users] Routes with captures
by Marc Chantreux 01 Jun '10

01 Jun '10

hello, > - r() already supports full regex patterns (perhaps without special extras such > as "/x" but that can be, I believe, patched.) it does! i wrote any [qw| post get |] , r( qr( / ([^/]+) # the class / ([^/]+) # the object / ([^/]+) # the action /?$ )x ) , sub { "Yeah" } and it worked! and then i was confused because the r() became useless noise. > r('/.+/\w+_\w/'); > is easier and more readable than: > qr/\/.+\/\w+_\w\//; > > It's true - however - that we could try and encourage a bit more readable regex > patters: > qr{/.+/\w+_\w/} > Still, readability suffers. qr(/.+/\w+_\w/); r('/.+/\w+_\w/'); Both are readable for me. > However, there are certain benefits to discuss and perhaps we'll add your > patched. Since it's not something so trivial, a discussion will ensue. :) Ok so i try to sell my point of view :) * r('') is code to maintain :-) * i really agreed your concern about readability but i don't understand why qr() is harder to read than r(''). I think qr() could be more readable in large applications: r('') does not use /x for the moment. as /x is a very good practice that is: - recommended in the "Perl Best Practice" - defaut behavior in perl6 - very addictive for those whom still use it so i think qr( / ( borrower | book | shelf ) # Bizness objects / ( delete | create ) # Crud actions / ( \d+ ) # id ) is way easier to maintain than r('/(borrower|book|shelf)/(delete|create)/(\d+)') About the feature proposed in my former message: qr( / (?<class> borrower | book | shelf ) # Bizness objects / (?<action> delete | create ) # Crud actions / (?<id> \d+ ) # id ) , sub { splat->{capture}->{action} } In the current Dancer behavior, you'll write '/:class/:action/:id' seems easier but: - you have to test all the captures in the code, which i think is a big readability issue: unless ( my ( $action = splat->{action} ) ~~ [qw/ delete create/] ) { not_found("$action isn't a valid action"); } - you'll match tons of urls too soon so it could be very hard to write smart dispatcher. for exemple, i think '/:class/:action/:id' can't be splitted in 2 rules like this get qr( / (?<class> program | library ) / (?<action> test | make ) / (?<id> \d+ ) )x, sub { "rule 1" }; get qr( / (?<class> documentation | tickets ) / (?<action> publish | alert ) / (?<id> \d+ ) )x, sub { "rule 2" } Finally, and even i prefer the qr() approach, i don't see why both syntaxes can't cohabitate in Dancer. regards, marc

3 10

Dancer on shared hosting
by Patrick Donelan 01 Jun '10

01 Jun '10

Hi Dancer people, I was playing with Dancer today, trying to work out the right recipe to get it running smoothly on a shared hosting account (documented here<http://perlsharedhosting.com/tech/dancer> ). I started with trying to get Dancer running in CGI mode, but for some reason I could get it to accept requests to '/', e.g. http://domain/dispatch.cgi/ Whenever I request that, it returns the contents of dispatch.cgi, even with the default route changed to r('.*'). Whereas requests to /dispatch.cgi/blah work fine. Sounds like an Apache problem right? The bizarre thing is that other simple plack CGI scripts work fine, and if I actually put a Data::Dumper::Dumper($env) into app.psgi, it actually dumps out the env hash (before returning the contents of dispatch.cgi), which seems to indicate it's actually running the script, but then bailing out or something. In case it helps, the dumped contents of $env are: *{ 'psgi.multiprocess' => 1, 'SCRIPT_NAME' => '/dispatch.cgi', 'PATH_INFO' => '/', 'HTTP_ACCEPT' => 'application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5', 'REQUEST_METHOD' => 'GET', 'PERL_MM_OPT' => 'INSTALL_BASE=/home1/muscleca/perl5', 'psgi.multithread' => 0, 'SCRIPT_FILENAME' => '/home1/muscleca/public_html/perlsharedhosting/dispatch.cgi', 'SERVER_SOFTWARE' => 'Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635', 'PLACK_ENV' => 'development', 'HTTP_USER_AGENT' => 'Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4', 'REMOTE_PORT' => '50243', 'QUERY_STRING' => '', 'HTTP_PRAGMA' => 'no-cache', 'SERVER_SIGNATURE' => '<address>Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635 Server at hostmonster.perlsharedhosting.com Port 80</address> ', 'HTTP_CACHE_CONTROL' => 'no-cache', 'HTTP_ACCEPT_LANGUAGE' => 'en-US,en;q=0.8', 'psgi.streaming' => 1, 'PERL5LIB' => '/home1/muscleca/perl5/lib/perl5:/home1/muscleca/perl5/lib/perl5/x86_64-linux-thread-multi', 'PATH' => '/home1/muscleca/perl5/bin:/usr/local/bin:/usr/bin:/bin', 'GATEWAY_INTERFACE' => 'CGI/1.1', 'psgi.version' => [ 1, 1 ], 'DOCUMENT_ROOT' => '/home1/muscleca/public_html/perlsharedhosting', 'psgi.run_once' => 1, 'PATH_TRANSLATED' => '/home1/muscleca/public_html/perlsharedhosting/dispatch.cgi/', 'MODULEBUILDRC' => '/home1/muscleca/perl5/.modulebuildrc', 'UNIQUE_ID' => 'TASHmkrc13MAAGkor0AAAAnZ', 'SERVER_NAME' => 'hostmonster.perlsharedhosting.com', 'HTTP_ACCEPT_ENCODING' => 'gzip,deflate,sdch', 'SERVER_ADMIN' => 'webmaster(a)perlsharedhosting.musclecarwebdesign.com', 'HTTP_CONNECTION' => 'keep-alive', 'HTTP_ACCEPT_CHARSET' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.3', 'SERVER_PORT' => '80', 'HTTP_COOKIE' => '__utmz=226470915.1275355275.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=226470915.680138832.1275355275.1275355275.1275357426.2; __utmc=226470915', 'REMOTE_ADDR' => '96.232.149.145', 'SERVER_PROTOCOL' => 'HTTP/1.1', 'psgi.errors' => *::STDERR, 'REQUEST_URI' => '/', 'psgi.nonblocking' => 1, 'SERVER_ADDR' => '74.220.207.74', 'psgi.url_scheme' => 'http', 'HTTP_HOST' => 'hostmonster.perlsharedhosting.com', 'psgi.input' => *::STDIN };* Thanks, Patrick

1 1

Re: [Dancer-users] Routes with captures
by Marc Chantreux 30 May '10

30 May '10

hello Sawyer, On Sun, May 30, 2010 at 07:27:32PM +0300, sawyer x wrote: > You can already use regexes as routes using r(). so i can't use usefull modifiers like i and x. plus i think that qr/.*/ comes more easily than r('.*') for a monger. don't you ? regards marc

1 0

Routes with captures
by Marc Chantreux 30 May '10

30 May '10

Hello all, Today, I cloned the dancer repo to add the ability to use Regexps as route (a one line patch). so, i can now write any [qw| get post |] , qr{ ^ / ( user | post ) / ( C|R|U|D | create | read | update | delete ) / ( \d+ ) /? $ }x , sub { my $url; @$url{qw/ class action id /} = splat; ...; }; I would like to go a bit further adding the support of perl 5.10 named captures. So the same code would become: any [qw| get post |] , qr{ ^ / (?<class> user | post ) / (?<action> C|R|U|D | create | read | update | delete ) / (?<id> \d+) /? $ }x , sub { my $url = splat->{capture}; # so $$url{action} ~~ [qw/ C R U D create read update delete /] ...; }; But i can ignore something about the current form any [qw| get post |], '/:class/:action/:id' => sub { ...; }; I appreciate to have your feelings abont that before writing some code that doesn't fit the spirit of the framework. Regards marc

1 0

best practices: how to require a login for parts of the site...
by Daniel Pittman 29 May '10

29 May '10

G'day. One of the requirements I am going to hit in the near future is that we will need to provide some public and some routes inside a single application. When users hit anything under a specific path, basically, they need to have an already validated login, or else we need to send 'em off to get one. The most basic "implement a login form" style thing pattern, nothing fancy. What I am curious about is the "best practice" way to achieve that inside the scope of Dancer, and how to make it a "drop in" part of other projects if I end up wanting to advocate wider use of Dancer in the company. My current model is to provide a plugin akin to this: package Dancer::Plugin::WithAuth; my $config = plugin_config; register with_auth (&) { my $handler = shift; return sub { session('user') or redirect $config->{login_path}, 302; goto &$handler; }; }; register_plugin; That then gets used with a route like this: get '/example/:arg' => with_auth { # normal handler here }; Is this the best approach to take to authentication for parts of the site? I considered the approach of hooking all requests and performing my own URL matching to determine if they should require authentication, but that seems to require that I duplicate an awful lot of code from the Dancer route system. Alternately, is there some feature of Dancer that I missed which would be easier to use for this? Oh. I did consider this construction, but found it hard to get right, especially if I wanted to cover '/admin' as well as pages under it. get r('/admin/.*') => sub { session('user') or redirect '/login', 302; pass; }; get '/admin/example' => sub { # ...should only be called *after* the first route calls 'pass' }; Is that just my messing up or something? Daniel -- ✣ Daniel Pittman ✉ daniel(a)rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons

2 1

Re: [Dancer-users] Dancer::Template::Alloy — in core, or my own module?
by Daniel Pittman 28 May '10

28 May '10

sawyer x <xsawyerx(a)gmail.com> writes: > On Mon, May 24, 2010 at 8:45 AM, Daniel Pittman <daniel(a)rimspace.net> wrote: [...] > Lastly, I should note that we try to keep track of all modules outside > Dancer using Task::Dancer and once you release Dancer::Template::Alloy, > I'll add it to Task::Dancer as well. Dancer::Template::Alloy is uploaded to PAUSE, and should make it's way out to mirrors over the next day or so. Feel free to list it in Task::Dancer. Daniel -- ✣ Daniel Pittman ✉ daniel(a)rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons

1 0

Dancer::Template::Alloy — in core, or my own module?
by Daniel Pittman 25 May '10

25 May '10

G'day. We have been trialing Dancer, and find it pretty darn good. The one thing we have done which is not in the current core is to use Template::Alloy in preference to the more common Template-Toolkit engine. I am not super-interested in advocating other people do the same; for us, it fixed some nasty bugs that caused problems without significant drawbacks, but for other people it might not have the same balance. Anyway, as part of that I wrote[1] Dancer::Template::Alloy, which is pretty much the Dancer::Template::TemplateToolkit module with the names changed. Is this something y'all would want to pull back into the Dancer core distribution, or should I throw it to CPAN under my own name? I see most of the other engines have gone as their own distributions, so I suspect this one should too, but wanted to ask the developers first. Daniel Footnotes: [1] Mostly search-and-replaced, to be honest. -- ✣ Daniel Pittman ✉ daniel(a)rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons

2 2

route_cache breaks with multiple parameters
by Stéphane 21 May '10

21 May '10

Hello, I've opened bug report 57158 where the following code: set route_cache => 1; get '/number/:cluster/:category' => sub { # your code here }; will provide incorrect params after a few attempts. I have had the same issue earlier with code like this: get '/number/:cluster/*' => sub { # your code here }; using splat(), but at the time I thought I had missed something in the documentation. I suspect this might be due to a similar problem. Running with route_cache: 0 will work around the issue. HTH, Stéphane

3 8

Dancer 1.1801!!
by sawyer x 19 May '10

19 May '10

Hello everyone, On behalf of the Dancer development crew, I would like to announce Dancer 1.1801. It should be available on CPAN soon enough. Even though it is not a big release, it contains an important fix for beginners[1] introduced by Alexis Sukrieh. We want to thank your alertness and for bringing it to our attention! :) * Another version will be released soon, stay tuned! [1] GH #69 http://github.com/sukria/Dancer/issues/closed#issue/69

1 0

First-time User: Notes
by Mark Lawrence 19 May '10

19 May '10

Hi, The clear documentation and articles I've seen on Dancer indicate it is my ideal base for a Perl web application. Having just downloaded the latest stable release however I have a couple of issues that I thought I would ask here before creating a trouble ticket. I'm running a mixed Debian stable/testing distribution (lenny/squeeze) with perl, v5.10.1 (*) built for x86_64-linux-gnu-thread-multi. 1. There appears to be duplicate subroutine definitions in the dancer script: mark@lifebook:~$ dancer -a myapp Subroutine main::dirname redefined at /usr/bin/dancer line 149 Subroutine main::path redefined at /usr/bin/dancer line 149 but this doesn't prevent the 'myapp' creation. 2. My 'myapp' starts fine, but all requests result in a 500 Internal Server Error. I have enabled logging and error publication in config.yml but am not seeing anything in either the http response or in the logs/development.log file. mark@lifebook:~/myapp$ cat config.yml layout: "main" logger: "file" log: "debug" show_errors: 1 So my two problems are that a) it doesn't work at the moment, and b) I can't seem to debug things. Looking for pointers to what I've read/done wrong... Cheers, Mark. -- Mark Lawrence

2 1