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

Dancer advent calendar 2012 - help wanted!
by David Precious 26 Nov '12

26 Nov '12

Hi all, It's that time of year again - advent calendar time! I think it would be nice to continue the tradition and do an advent calendar again, and I'm happy to put in the work writing some articles and coordinating effort, so, let's do it! With that said, help would of course be greatly appreciated :) I have updated the README in the advent-calendar repo at: https://github.com/PerlDancer/advent-calendar I've added some article ideas there already; more ideas, and volunteers to write some of them, would be awesome. The advent calendars in previous years have been an interesting way to get extra attention for Dancer, and do pull in quite a few views. Analytics shows that they continue to receive views all year round, too. (To give an idea how many, from Jan 1st 2012 to present, 12,271 people visited the advent calendar site; 24,969 visits in total, with 43,510 pageviews, 47% being new visitors, with an average visit duration of 01:50, and average 1.74 pages per visit. That's some effective marketing, and well worth adding to, I think! :) ) Cheers Dave P -- David Precious ("bigpresh") <davidp(a)preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github

8 16

Dancer::Plugin::Auth::Extensible - an authentication & access control framework for Dancer apps - RFC
by David Precious 25 Nov '12

25 Nov '12

Hi all, I've finally had time to hack further on the new Dancer authentication / access control plugin I've been working on, and it's at a state where I plan a beta CPAN release soon. The module is Dancer::Plugin::Auth::Extensible, and can be found on GitHub: https://github.com/bigpresh/Dancer-Plugin-Auth-Extensible I've written this as I tried to use D::P::Auth::RBAC, but I never really got on with it, and IMO it needed a lot of work - so I decided to write this from scratch. The plan is to make user authentication and access control dead simple, whilst also being extensible. I'd very much appreciate comments and suggestions from anyone who has time to look. Just to give an idea how it works - you configure the plugin via the app's config file (exactly what you put in depends on the authentication provider you're using), then denote which routes require authentication or specific roles using subroutine attributes - for instance: get '/secrets' => sub RequiresLogin { tell_secrets(); }; get '/really-secret' => sub RequiresRole(BestFriend) { tell_everything(); }; The first role could be accessed by anyone who is logged in; the second can only be accessed by people with the specified role. (If you only need basic authentication and not roles, you can ignore the role features; if you later need roles (e.g. you realise you need some users with higher privileges than others) it's trivial to start using them. The example app shipped with the module is a good place to look for a simple example: https://github.com/bigpresh/Dancer-Plugin-Auth-Extensible/tree/master/examp… The framework is designed to to be flexible enough to use various methods of authentication via the "provider" classes, and for new providers to be easy to write. All provider classes inherit from a base class which provides a constructor, ensures the provider implements the required methods, and provides a simple way to validate crypted passwords, so there is no reason that passwords should be stored in plain text, ever. So far, there is a "Config" provider which authenticates against usernames and passwords in the app's config, a "Database" provider which authenticates against a database (using the Database plugin), and a "Unix" provider which authenticates against system accounts on a *nix-type box. A DBIx provider is coming soon, and others (such as IMAP/LDAP) may well be provided too. As the framework supports multiple realms, it's possible to configure it to e.g. look in a database first, then try an IMAP server. A basic login page, login handling code etc is provided automatically, but can be overridden if desired. I'm about to put this in to use myself; I'm hoping it will be of use to other people, too. So, please do let me know what you think, whether it's of use to you, and whether there are any features that would make it more useful to you! I plan to tidy up the code a little and and improve the documentation before a proper release, but it's in a position where I'm fairly happy it works as it should, and already has a test suite of > 30 tests which pass happily. Cheers Dave P -- David Precious ("bigpresh") <davidp(a)preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github

1 0

[Dancer2] Dancer::Template::Simple
by Damien Krotkine 01 Nov '12

01 Nov '12

Hi, So, now I'm puzzled :) I thought we wanted to get rid of Dancer::Template::Simple and use Template::Tiny. Why then do we still have Dancer::Template::Simple in Dancer2 ? Is it for backward compatibility ? does it need to be removed soon ? Thanks

2 1

Template::Tiny forkage
by Damien Krotkine 01 Nov '12

01 Nov '12

Hi, As discussed previously, Dancer2 now embeds its own Dancer::Template::Implementation::ForkedTiny. I know the name is awful :) However, please let me know of any template issues you have with this new version. This new T::Tiny forked version open the path to more plugin compatibility, including FlashMessage and FlashNote. https://github.com/PerlDancer/Dancer2/commit/582447e3873df9db00ca4659b3df82… dams.

2 3

Re: [Dancer-users] recommended way to return large dynamic data?
by Maurice Mengel 31 Oct '12

31 Oct '12

I guess you don't want to split it your response into pages (50 hits or so per page), you seem to want to stream a file to your users (without writing it to server hard disk). I looked into that a long while ago, got it to work in a test, but never used it in production. It's mentioned http://search.cpan.org/~xsawyerx/Dancer-1.3110/lib/Dancer.pm#send_file.

4 8

Testing new list
by David Precious 30 Oct '12

30 Oct '12

Hi, (Not sure what happened to my last test mail; my mail client shows it in my sent box, but won't display it, so I think it failed oddly.) Anyway, just testing the dancer-users list as hosted on my Mailman install, to check I've ported over the list settings, membership list and archives etc correctly. Hopefully this will work this time. If so, the new canonical list address is dancer-users(a)dancer.pm - but I'll ask Sukria to forward on the existing address so it'll still work. Cheers Dave P -- David Precious ("bigpresh") <davidp(a)preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github

8 8

Re: [dancer-users] Test dancer-users list on new server
by sebastien deseille 30 Oct '12

30 Oct '12

Hello David It is right regards Sébastien Deseille 2012/10/30 David Precious <davidp(a)preshweb.co.uk> > > Hi, > > Just checking the dancer-users list works on my Mailman setup. > > Assuming this list is received and archived etc, we should be in > business. > > New list posting address will be dancer-users(a)dancer.pm - although I'll > ask Sukria to forward on the old address so it still works. > > Cheers > > Dave P > > -- > David Precious ("bigpresh") <davidp(a)preshweb.co.uk> > http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter > www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook > www.preshweb.co.uk/cpan www.preshweb.co.uk/github > > > _______________________________________________ > dancer-users mailing list > dancer-users(a)dancer.pm > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users > -- -- Cordialement Sebastien Deseille

1 0

Using configuration files with other formats than YAML
by Octavian Rasnita 18 Oct '12

18 Oct '12

Hi, I've seen that Dancer can use just YAML configuration files and no other formats like JSON, ini, Apache or others. Are there specific reasons for this limitation? I use a short and dirty code that allows using all types of configuration files supported by Config::Any: use Dancer ':syntax'; use FindBin; use Config::Any; my $config = Config::Any->load_stems( { stems => [ "$FindBin::Bin/../config" ], flatten_to_hash => 1, use_ext => 1 } ); my @config = %$config; $config = $config[1]; set $_ => $config->{$_} for keys %$config; my $env = Config::Any->load_stems( { stems => [ "$FindBin::Bin/../environments/" . config->{environment} ], flatten_to_hash => 1, use_ext => 1 } ); my @env = %$env; $env = $env[1]; set $_ => $env->{$_} for keys %$env; After doing this I can use configuration files like config.yml, config.conf, config.pl... and environments/development.yml, environments/development.conf... each one with their specific format. In the code above I used just a single configuration file, but with a code just a little bit longer the app could get and use the vars defined in more files with the same name and different formats if it is needed, but that thing is probably not very useful. The question is, wouldn't be better if Dancer would use Config::Any in core? It would be more flexible and Config::Any doesn't require other modules. Those modules will be installed only by those who need them. --Octavian

2 1

Masking warnings with eval/try in development mode?
by Assaf Gordon 17 Oct '12

17 Oct '12

Hello, I'm working on a website, currently in 'development' mode. The config has "warnings: 1", meaning "treat warnings as critical errors", which is what I want 99% of the time. However, there's one place were I want to try something that might fail, and proceed without stopping the dancer application. Something like: === get '/foobar' => sub { my $ok; eval { do_something_that_might_fail(); $ok = 1; }; template 'foobar', { ok => $ok } ; }; === However, in development mode with "warnings: 1", the "do_something" die()s and the dancer application stops with the standard HTTP 500 page with the stack trace. I don't want to turn "warnings" off, but I want to be able to mask this specific warning. Any ideas ? Thanks, -gordon

3 4

Dancer occasionally eats lots of memory
by Konstantin A. Pustovalov 17 Oct '12

17 Oct '12

Hello guys! I have found that dancer's memory consumption is indeterminant. I am writing RESTful statistics service. Have discovered that dancer can consume lots more memory with one request than another with essentially same POST body size. Some tests: http://pastebin.com/yuy1ZKfn The output: http://pastebin.com/YDHqLzQh You can see that when I send ~12MB json string (~20MB hash in memory) dancer can consume ~ 24MB when data is sent as nested hash or ~81MB (4x!) when sent as-is. Tranfering dozens of MBs of statistics is normal in my service, so it can hit swap easily by clients mistake. What can I do to make dancer behave predictably in memory consumption? May be I am doing something wrong?

4 4