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

Order of loading plugins
by Rolf Schaufelberger 28 Dec '12

28 Dec '12

Hi, as I wrote in my previous mail I'm just testing Dancer if it can replace my current framework. Currently I'm using DBIC (and like to keep it) and I store some parameters and all my i18n stuff in a database. So at server startup I need at first my DBIC connection settings to be able to pull my other settings and my localization stuff from database. While I'm not shure yet, whether I can use some of the existing plugins for I18N, the general question for me is, how can I configure the order, how plugins are loaded and initialized ? Regards Rolf Schaufelberger

2 2

Dancer::Session and cookie path of session cookie
by Jens Rehsack 28 Dec '12

28 Dec '12

Hi David, hi Dancer users, as talked in mid of December on irc.perl.org/#dancer I had some trouble with Dancer::Session::Cookie and the cookie path. I used 'session_cookie_path' set to a restricted area of a dancer app (requirement - don't ask), but on some circumstances the path was used or not. Later I figured out that Dancer::Session forces cookie rewrite using Dancer::Session::Abstract->write_session_id and when a session key/value was updated, Dancer::Session::Cookie->flush uses it's own cookie update mechanism. First I added the ability of restricting session cookie path to Dancer::Session::Abstract (and fix some function calls into methods). Then I forgot to install the fix and search for some hours the test failure in upated Dancer::Session::Cookie. This mail includes the patches for Dancer itself - follow up mail includes the patch for Dancer-Session-Cookie dist. Would be great if you could review and/or apply or find someone who could. Thanks in advance, Jens PS: Happy New Year, everyone!

3 3

How to work with Dancer2 ?
by Celogeek 27 Dec '12

27 Dec '12

Hi, I have start hacking Dancer2 project. I have multiple question : - I know people are busy, but how long take a patch to be merge after 2 validations and 3 weeks still waiting ? I'm waiting to see if the project is still active to add futher patches. - I want to update my Dancer::Plugins::Redis, but I'm a little bit lost on the right way to do it. How to be compatible with v1 and v2 ? - Is they an equivalent website as perldancer.org for perldancer2 ? - I have start writing App::Dancer2 (already push on cpan), based on the Dancer2 mainline git repository example. Is they a doc somewhere to do stuff more complicated ? - is they a list of Dancer2 already patched module ? I think a website like " https://www.djangoproject.com/" or " http://rubyonrails.org/" or "http://perldancer.org" could be great to speed up the passage from v1 to v2. Having a good tutorial to start a Dancer2 project, and to create some awesome Dancer2::Plugins is essential. A place where all of this can be found. What do you think ? I was thinking of a kind of wordpress website (like mine :) http://blog.celogeek.com ) to push our discover, our tutorial ... Any contributor could push their discover. Something : Starting a new Dancer2 project Starting a new Dancer2 Plugins How to upgrade your Dancer1 plugins to be compatible with Dancer2 How to create a Dancer1 / Dancer2 plugin Hacking Dancer2, how to post your patches Our IRC ... If anyone is interested, I can work on it and take the perldancer2.org domains if needs. Please tell me, I'm motivated. Thanks.

4 4

dancer_major_version
by damien krotkine 27 Dec '12

27 Dec '12

Hi, As I understand, Alexis did a dev release of dancer2. The version is 1.9999_01 or something like that. People and plugins currently uses int(dancer_version) to discover if it's running under Dancer 1 or Dancer 2. int(1.0000_01) emits a warnings, so to work around that, a ne keyword has been added : dancer_major_version, which returns what's on the left of the dot in the version number. Fine, except that : - this keyword has not been added to Dancer v1, so plugins using dancer_major_version will break under Dancer 1 - no advertizing has been made on to what plugins should use (ie continue using int() or use the new keyword) What's the best solution ? In my opinion we can : 1/ Release a new Dancer 1, and ask people to use dancer_major_version and require the latest Dancer 1 release (or Dancer 2) : long and cumbersome as we need to potentially modify plugins and contact users and so all 2/ remove dancer_major_version, and change dancer_version so that it returns the version without the _xx at the end. Simple, doesn't need to release D1 again, and nothing to change in plugins. 3/ any idea ? As you may guess, I'm a big fan of solution 2. If you all agree (especially sukria, as he added dancer_major_version, and maybe he had an other reasons for that), I can make the change. In my opinion, the longer we stay in the current situation (dancer_major_version only in D2), the more dangerous it is dams.

6 9

DANCER_CONFFILE support with test
by Jens Rehsack 27 Dec '12

27 Dec '12

Hi everybody, some time ago I initiated a discussion at irc.perl.org/#dancer regarding the config file name (always the same, what might create conflicts when installing multiple Dancer based applications into a same file-system prefix). This conflict can currently only resolved by creating sub-directory for config.yml for each application, what is a waste of i-nodes and reduces clear arrangement of configurations. Attached is a patch which allows operators of Dancer based applications to choose individual names for the configuration file depending on operation and/or developer guidelines. Happy New Year, everyone! -- Jens Rehsack

1 0

Dancer::Plugin::Auth::Basic on Windows
by Jesse Thompson 26 Dec '12

26 Dec '12

I'm attempting to port a Dancer app to Windows. So far, all of the dependencies have installed fine, but cpanm fails to install Dancer::Plugin::Auth::Basic Building and testing Dancer-Plugin-Auth-Basic-0.02 Can't open README.pod for writing: Permission denied at C:\Users\zjt\.cpanm\work\1355758680.3396\Dancer-Plugin-Auth-Basic-0.02\_build\lib/My/Builder.pm line 11. It appears that the path .../My/Builder.pm is assuming the OS is *nix. Anyone know if a way to fix this? Jesse

4 6

Patch to fix exception serialization under JSON/XML (https://github.com/PerlDancer/Dancer/issues/877)
by Rik Brown 24 Dec '12

24 Dec '12

Hi all, I just raised this bug, and made a patch for it. Details are at https://github.com/PerlDancer/Dancer/issues/877 - but in short, Dancer::Error passes the Dancer::Exception::* object through to the serializer, which then explodes because (certainly for JSON/XML) it is not configured to support serialising objects (and probably shouldn't be!). The patch removes sending this exception through. In the case of JSON/XML, this never worked, but for non-object exceptions (i.e. die "some string"), it changes the response from having identical 'error' and 'exception' keys to having only an 'error' key. I'd appreciate any feedback on the (2 line!) patch - this is my first time contributing to Dancer so I may not be following procedure properly :-). Cheers - and have a great Christmas everyone! -- Rik Brown http://www.rikbrown.co.uk

1 0

Introducing Dancer::Plugin::Auth::Tiny
by David Golden 19 Dec '12

19 Dec '12

Hi, everyone. The fascinating DPAE discussion prompted me to write a Tiny auth plugin with some similar concepts. Because I already have user authentication working -- and because I think that logic should live in the model, not in the controller -- the "wrap routes" feature of DPAE was great sugar, but I didn't want the authentication backends or the default login/logout handlers. So... I wrote just the sugar part, and left all the actual authentication up to the user. Here's the synopsis -- note the 'needs login' in the '/private' route handler line: use Dancer::Plugin::Auth::Tiny; get '/private' => needs login => sub { ... }; get '/login' => sub { # put 'return_url' in a hidden form field template 'login' => { return_url => params->{return_url} }; }; post '/login' => sub { if ( _is_valid( params->{user}, params->{password} ) ) { session user => params->{user}, return redirect params->{return_url} || '/'; } else { template 'login' => { error => "invalid username or password" }; } }; sub _is_valid { ... } # this is up to you Plus, it's extensible, if you want to replace the 'login' wrapper with your own, or if you want to add additional wrappers for your own needs. I'd love to hear feedback, so please check it out: https://metacpan.org/module/Dancer::Plugin::Auth::Tiny David -- David Golden <xdg(a)xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg

1 0

Dancer::Plugin::Auth::Extensible - removing sub attributes - ready to try out
by David Precious 19 Dec '12

19 Dec '12

Hi all, Following the recent discussion on the list regarding DPAE's use of subroutine attributes to declare which routes need auth/specific roles and a before handler to check for them, the general consensus seems to be that, whilst the attributes-based approach is quite clean, it's not necessary solid enough to rely upon. (Multiple people whose opinions I respect advised me that there are likely to be issues with it - some potential problems include thread safety, and problems I've seen at work when running under the debugger / Devel::Cover etc.) For that reason, whilst DPAE is still young and not widely used (as far as I'm aware :) ), I've decided it would make sense to take the approach recommended by multiple people, and replace sub attributes with keywords which wrap the route handler coderef and perform the required checks before executing it. The changes are in a remove_attributes branch - the refactor commit is: https://github.com/bigpresh/Dancer-Plugin-Auth-Extensible/commit/32844b7c3c… From a user's point of view, the changes are in how you define that a route needs login / specific roles. Previously, you would say: get '/secret' => sub :RequiresLogin { ... }; Now, you'd say: get '/secret' => requires_login sub { ... }; And to require specific roles: get '/beer' => requires_role BeerDrinker => sub { ... }; Opinions on this would be warmly welcomed. Also, if you've been using DPAE and have a moment to try out your code with these changes, that would be awesome. DPAE passes all its tests after the changes, so I'm reasonably convinced that it's working correctly, but will perform more testing before this hits CPAN. 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

5 9

Global keywords still in Dancer 2?
by gvim 18 Dec '12

18 Dec '12

I like a lot about Dancer 1 but I don't like the PHP-ish style of having all the helper kewords/functions in the global namespace. I'm coming to Dancer from CGI::Application where we have a persistent $c object, as with Catalyst. Is this approach built into Dancer 2 or is it still using the same global namespace approach? I'd like to be able to be able to: my $d = new Dancer; OR my $d = Dancer->new(); ...... $d->session(); $d->template(); etc. gvim

6 8