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

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

http put to upload large file
by halayudha 05 Aug '11

05 Aug '11

hi, i have problem to upload file using HTTP PUT with large file 800MB. i use 'upload', which is alright for small file size. may be some one can enlighten me with regard to my issue? juniarto halayudha

5 9

Possible Dancer::Plugin::Ajax bug
by Dave Seleno 05 Aug '11

05 Aug '11

In my Dancer application, I have three different handlers for the same path, based on the request method: ajax '/some_path' => sub { ... return to_json({...}) ; } post '/some_path' => sub { ... return redirect '/some_path' ; } get '/some_path' => sub { ... return template 'some/template' => { ... } ; } What I am seeing is that, occasionally and with no pattern I've yet been able to reproduce, when a GET is issued to /some_path, the process is handled by the correct GET handler, but the response comes back without the layout. There are no errors in the log. From the documentation of Dancer::Plugin::Ajax, disabling the layout is what one would expect only when the AJAX handler was triggered. Issuing another GET immediately after typically "fixes" the problem and the response comes back with the layout intact. Has anyone else experienced this? Regards, Dave

1 0

RPC and Exception Handling
by Tim King 02 Aug '11

02 Aug '11

Hi, all. We're developing an XML-RPC web service using Dancer, and I thought one of you might be able to give us some pointers. We thought that developing an XML-RPC serializer would be the right approach. The serializer would decode the XML-RPC request and encode the XML-RPC response. However, we ran into a couple problems: 1. An RPC request contains a method name, as well as the method parameters. On deserialization, the RPC serializer would have to rewrite the request object, modifying the request path as specified by RPC method contained in the request body. However, the Dancer serializer API only allows the serializer to set request parameters, but not other fields of the request. The only way the serializer can modify the request path is to do so as a side-effect, via Dancer::SharedData, which strikes me as poor design. 2. Certain error conditions in the serializer and in the request handler need to be able to generate an RPC fault message. In particular, we'd like to be able to throw exceptions and have them caught by the infrastructure, which would then convert them to appropriate RPC fault messages. But Dancer doesn't seem to have any way to catch exceptions thrown from handlers or to insert app-specific code into the Dancer call graph. We can't even subclass Dancer::Route, for example, and extend it, because Dancer provides no way to inject our app-specific classes into Dancer's framework. (We were particularly disappointed at this discovery.) So the approach we're working on now is to use an RPC plugin. This plugin decodes the RPC request, creates a new request object for the RPC method, then calls Dancer::Handler->handle_request() to route it to the correct handler. Then it encodes the response back into the corresponding RPC response format. The plugin code will also catch exceptions that the handlers throw, converting them as appropriate into RPC faults. Comments? Do you think we're on the right track? Thanks, -TimK

2 1

What's wrong with Dancer add-ons on search.cpan.org?
by Flavio Poletti 02 Aug '11

02 Aug '11

Hi, some time ago I noticed that three modules of mine related to Dancer had a one-star rating when browsed from search.cpan.org. Curious about these bad rating, I tried to look at the reviews but I found none. I tried to write to both search.cpan.org and perl.org contacts with no answer (possibly due to the vacation-intensive period, but some autoresponder would have been appreciated). After 10 days the bad ratings are still there, so I was curious to see whether I was the only one impacted and I discovered that I'm not. Most Dancer extensions have one-star ratings and no review at all, even though there seem to be reviews according to the search page. E.g. see http://search.cpan.org/search?m=all&q=dancer&s=41 What do you think about it? What can we do? Cheers, Flavio.

5 5