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

Routing: captures in prefix
by Michele Beltrame 19 Aug '11

19 Aug '11

Hello! I'm just beginning with Dancer - looks like a great framework to me - and I have a question. I have the following code: ------------------ package stelage::products; use Dancer ':syntax'; get '/:lang/products/' => sub { return vars->{lang} . ' is the language'; }; ------------------ This works and allows me to use URIs such as: myapp/it/products/ myapp/en_US/products/ etc... I'd like, however, some more automation on this by using the "prefix" keywords, but it doesn't seem to work with prefixes. So, this: ------------------ prefix '/:lang/products'; get '/' => sub { return vars->{lang} . ' is the language'; }; ------------------ doesn't match. I also tried with regular expressions in routes, but didn't work either. Is there a way to make this work, without resorting tu URL rewriting? Thanks in advance, Michele. -- Michele Beltrame http://www.italpro.net/ - mb(a)italpro.net Skype: arthas77 - Twitter: _arthas

5 6

redirect to https
by Nick Knutov 19 Aug '11

19 Aug '11

In some control panels I need to redirect all users on https, something like before sub { return redirect 'https://'.request->host.request->request_uri if config->{environment} eq 'production' and not request->env->{HTTP_HTTPS}; [...] }; Is it a good way? My be it's already automated by some flag in config.yml? Additional, I found that password from session_cookie_key is not hidden when error occurs and show_errors: 1. it's a bug, I think. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130

1 0

Hidden setting forcing production environment.
by Michael Genereux 16 Aug '11

16 Aug '11

I don't know if anyone sees GitHub comments so I'll post here. In public/dispatch.cgi, there's a setting that forcibly sets the environment to production. The docs current provide information that has no effect. Here's what I posted: This setting really screwed me up as a new user of Dancer. (Loving it BTW.) The docs said to use Apache Environment variables and yet I couldn't get into development mode. Once I traced and commented this line out, Apache SetEnv worked great for me. I have development, staging, and production on a set of identical servers and they have same code but different environments controlled by Apache. I'm guessing no one else is doing development with Apache and is using the standalone app runner mostly. Should I submit a patch removing the Apache SetEnv docs? http://search.cpan.org/~sukria/Dancer-1.3071/lib/Dancer/Deployment.pod#Runn…

2 1

do something after sending response
by Nick Knutov 15 Aug '11

15 Aug '11

Hello all, is it possible to run some code after sending response to upstream [and closing socket] with Dancer? For example: I want to get request, send response and after closing socket to back-end do some job with big timeouts: write logs, send notifications via emails, etc. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130

11 18

Dancer::Exception
by damien krotkine 12 Aug '11

12 Aug '11

Hi, I'm in the midle of doing the second round coding for Dancer::Exception (it's in topic/exceptions2 on github). I have few design questions, and I'd like some feedback from the community. The plan is that with Dancer::Exception : - 1/ an exception has a value ( combination of power of 2 integers), and a message (string) - 2/ all exceptions raised by the Dancer core will be Dancer::Exception (instead of normal die / croak) - 3/ a user will be able to raise exceptions in the routes - 4/ a user will be able to create new exception types - 5/ when raised, exceptions are transmitted to the templating system when rendering a Dancer::Error - 6/ exceptions should properly stringify and numerify for backward compatibility and ease of use. - 7/ the user should have the opportunity to catch any Dancer exception and perform an appropriate action Currently, in the topic/exceptions2 branch, all items are implemented, except item 7. More precisely, it's possible to catch Dancer::Exception using standard eval {...}. But what if a user wants to catch an exception raised from a distant route, or from Dancer Core itself ? Real life example 1 : in some routes, the developer does some 'raise' of exceptions (internal or custom). The developer wants to run specific codes when these exception are raised. For now, he can wrap his route code with eval {} and use is_dancer_exception, as stated in Dancer::Exception. Real life example 2 : in some routes, the developper wants to catch core exceptions that could occur. Real life example 3 : if something wrong happens in the Dancer::Session::Yaml modules, it raises a E_SESSION exception. When this exception occurs, it'll render a Dancer::Error, stating that thet exception were a E_SESSION. However what would be cool is that you could catch the exceptions, see that it's of type SESSION, and in this case try a different Dancer::Session system. In this case the exception is a core one. example 3 is not related to routes, so it's a bit difficult to know where to put a try/catch scope. I have some ideas, but I'm not really convinced by them : - idea 1 : add a new hook, that would be called 'after_exception' - idea 2 : when an exception is raised, it's stored as Shared Data, and thus can be detected with a before_error hook - idea 3 : add a try_catch syntax when creating route, like : get '/foo' => sub { ... raise E_LOGIN, "bad credential" }, catch E_REQUEST | E_GENERIC => sub { ... } catch E_LOGIN => sub { ... } Currently, Dancer::Exception is not too bad : it's simple, efficient and fast. I don't want it to become a bloated system. But we need to provide a bit more feature for it to be really useful. Please share your thoughts :) dams.

2 2

Re: [Dancer-users] do something after sending response
by al 12 Aug '11

12 Aug '11

I thought about this the other day. I like the forking technique, but I suggest that if you install a signal handler in the main Dancer process upon startup, it should automatically reap any dead children and then you can fork to your hearts content without worrying about zombies. $SIG{CHLD} = sub { wait(); }

1 0

Writing tests for Dancer::Plugins
by Colin Keith 11 Aug '11

11 Aug '11

Hi, I'm a newbie to Dancer but so far I like a lot of what I see. I wanted to try it out by rewriting some of our crusty old CGI apps to Dancer to give me some experience with it. Needless to say that means the usual coding horrors of old code, no test suite, so many issues that Perl::Critic pretty much just goes "blah". This time around I wanted to keep things modern and include coverage tests, etc. so I'm looking for advice on the best practices within the Dancer community. More specifically I just finished writing a plugin for Dancer but being a plugin I'm not sure how to write the tests. What is considered the best way to approach testing them, whip up a quick dancer app in a test file? Also, since I'm asking for best practice info; 1. Is it considered better to release to Github and then to CPAN per Dancer itself? 2. Are there any guidelines on the naming of Dancer plugins 3. Does any one have any good refs for writing unit tests. Most things I've read so far only say how great their (yet another) Test::* module is, cover the basic stuff over and over. I know how to write the tests, I'm trying to determine what is considered a good level of writing tests. My obsession comes from having discovered that you can Hudson for CI with Perl. Thanks in advance. Colin.

3 4

Dancer::Plugin::I18N::TextDomain
by Colin Keith 11 Aug '11

11 Aug '11

So while it is lunch time I thought I should post this. Thanks to the help from SawyerX and David Precious I finally got around to putting my first plugin on Github last night. https://github.com/colinmkeith/Dancer-Plugin-I18N-TextDomain It isn't spectacularly complex and it still needs the in-app tests added, but hopefully it is useful. Please feel free to comment. Thanks. Colin -- Colin Keith

2 1

Two years of Dancer!
by David Precious 07 Aug '11

07 Aug '11

Hi all, Today marks two years to the day since the first version of Dancer hit CPAN! According to the BackPAN, Dancer-0.9003.tar.gz hit CPAN on 07-Aug-2009.[1] I think you'll agree we've come a long way since then, thanks to the awesome community and user base built up around the project since then. In these two years, we've had countless valuable contributions from a large list of contributing users (see the list on the about page[2]), gathered over 300 watchers on GitHub, had 84 people fork the repository on GitHub, had 620 pull requests submitted... amazing stuff. We've seen a wide range of awesome Dancer plugins[3] appear on CPAN. We've seen Dancer presented at various conferences including FOSDEM, OSDC.fr, the French Perl Workshop, the Bulgaria Perl Workshop, PyWeb IL (a Israeli Python group). We've seen screencasts on using Dancer (thanks Gabor!), we've seen Dancer discussed plenty within the Perl community with plenty of helpful suggestions. Unfortunately, we've also seen some trolling from someone who, for reasons unknown, seems to take a strong dislike to the project - puzzling. As a result of some of the trolling which included fake reviews falsely attributed to members of the Sinatra team, we've seen our initial inspiration, Ruby's Sinatra project, release a statement proclaiming that "Sinatra Loves Dancer"[4]. So, to celebrate Dancer's 2nd birthday, I think a little marketing effort would be good - I'd like to invite you all to let the world know what yout think! Do you use Dancer? Do you like it? Let people know - blog about it, tweet about it, leave positive reviews & ratings on cpanratings.perl.org[5] or +1's on MetaCPAN[6] - however you like. (If you leave reviews/+1's, feel free to also do so for any Dancer plugins you find helpful, too - they need the love too! :) ) Also, if you don't already, please "watch" the Dancer project on GitHub[7] - just go to the project page and click the "Watch" button near the top. Pithy quotes on what you like about Dancer suitable for inclusion on www.perldancer.org/testimonials would be very welcome, too :) Also, we've come a long way, but we have a long way to go, too - we have some great improvements to Dancer planned, but suggestions for new features would be very welcome - it's always good to know what users would like to see! So, happy birthday Dancer, and happy dancing, community! And, of course, an invitation - if you're interested in Dancer, but aren't already part of the vibrant welcoming community in the #dancer IRC channel on irc.perl.org, feel free to join us - see http://www.perldancer.org/irc for a web chat client if you don't use IRC normally. [1] http://backpan.perl.org/authors/id/S/SU/SUKRIA/ [2] http://www.perldancer.org/about [3] http://p3rl.org/Dancer::Plugins (update due in next release, btw) [4] http://www.sinatrarb.com/2011/07/21/sinatra-loves-dancer.html [5] http://cpanratings.perl.org/dist/Dancer [6] https://metacpan.org/module/Dancer [7] https://github.com/sukria/Dancer (I also posted this to my own blog at: http://www.preshweb.co.uk/2011/08/happy-birthday-dancer/ - we need to get the Dancer project blog up and running, I'll make serious efforts to get that sorted in the next few days.) Cheers Dave P -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)

2 1

Re: [Dancer-users] Dancer-users Digest, Vol 18, Issue 4
by Colin Keith 07 Aug '11

07 Aug '11

On Thu, Aug 4, 2011 at 6:00 AM, <dancer-users-request(a)perldancer.org> wrote: > From: David Precious <davidp(a)preshweb.co.uk> > Subject: Re: [Dancer-users] Writing tests for Dancer::Plugins > To: dancer-users(a)perldancer.org > Message-ID: <201108031317.59264.davidp(a)preshweb.co.uk> > Content-Type: Text/Plain; charset="iso-8859-1" > > On Wednesday 03 August 2011 06:06:07 Colin Keith wrote: > That's basically the approach used for the tests for Dancer::Plugin::Database > > https://github.com/bigpresh/Dancer-Plugin-Database/blob/master/t/01-basic.t > https://github.com/bigpresh/Dancer-Plugin- > Database/blob/master/t/lib/TestApp.pm > > A test app which exercises the plugin, and a test script that calls the test > app and checks the results it gets match what's expected. Ahh, thank you. I knew I had seen that approach used in a module's test code, but I couldn't remember which it was. > Generally, yes. Push to GitHub often, and when you're ready to make a stable > release, create a tag and release to CPAN (Dist::Zilla can make this very > easy, although I've not got round to learning to use it yet, I still do it the > old-school way :) ) Okay, thank you for the advice. > Well, they should start with "Dancer::Plugin::" really; ideally, try not to be > too generic if possible to avoid hogging namespaces. Feel free to describe > what a plugin does and ask for naming suggestions from the community. I wrote a plugin to Locale::TextDomain as I find it the easiest interface to libgettext (after I bashed my head against the desk with all of them). I use it in my TT templates in our software to allow owners of the software to customize the test, particularly the language of the text that is output so I called my lib Dancer::Plugin::I18N::TextDomain I assume that there would be alternative plugins for other i18n interfaces so I didn't want to hog the I18N name space. > It's useful to write tests before fixing bugs for regression testing, too - if > a bug is reported, write a test which tickles the bug and fails, then fix the > bug - once the test passes, you know you fixed it, and you know if that bug > comes back in future, that test will catch it. Thank you. I usually just get on and fix them, but that is a very helpful suggestion. Colin.

2 1