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

CODE in export_symbols_to
by Hao Wu 17 Mar '13

17 Mar '13

Hi Dancers, I am reading the dancer2 code and can not figure out what the CODE means here. Could anyone give me some direction? Thanks. Dancer2/Core/Role/DSL.pm 44 sub export_symbols_to { 45 my ($self, $caller, $args) = @_; 46 my $exports = $self->_construct_export_map($args); 47 48 foreach my $export (keys %{$exports}) { 49 no strict 'refs'; 50 my $existing = *{"${caller}::${export}"}{CODE}; 51 52 next if defined $existing; 53 54 *{"${caller}::${export}"} = $exports->{$export}; 55 } 56 57 return keys %{$exports}; 58 }

1 1

session->{} doesn't work?
by Octavian Rasnita 17 Mar '13

17 Mar '13

Hi, I read that we can use both: session('key') and session->{key} ...in order to get a value from the session. I tried: template 'login', { message => session->{flash} }; but it didn't work. However, the following worked: template 'login', { message => session('flash') }; --Octavian

4 5

before hook
by Octavian Rasnita 17 Mar '13

17 Mar '13

Hi, In Dancer2::Cookbook I read: before sub { if (! session('user') && request->path_info !~ m{^/login}) { var requested_path => request->path_info; request->path_info('/login'); } }; But it doesn't work and it gives an error. So I tried to change it with: hook before => sub { if ( !session('user') && request->path_info !~ m{^/login} ) { var requested_path => request->path_info; request->path_info('/login'); } }; This doesn't give an error, but I am not sure if it works as it should. I thought that the following line should execute the subroutine for /login: request->path_info('/login'); but this doesn't happen and the subroutine for currently requested path is executed. Is it possible to protect all the paths under a certain path, say /admin, by checking in a single place if the user is logged in, and if it is not, print the login form? --Octavian

1 0

Installing Dancer 2 using cpan
by Raman Pandarinathan 17 Mar '13

17 Mar '13

Hi, I am trying to install Dancer2 using cpan. It fails in tests. Here is the message #cpan Dancer2 .. .. .. t/logger.t ..................... 1/? # Failed test at t/logger.t line 28. # '[test:15649] debug @2010-06-15 05:30:00> foo in t/logger.t l. 27 # ' # doesn't match '(?^:debug \@2010-06-1\d \d\d:00:00> foo in t/logger.t)' # Looks like you failed 1 test of 3. t/logger.t ..................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests .. ... ... Test Summary Report ------------------- t/logger.t (Wstat: 256 Tests: 3 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=70, Tests=863, 19 wallclock secs ( 0.41 usr 0.12 sys + 16.11 cusr 1.50 csys = 18.14 CPU) Result: FAIL Failed 1/70 test programs. 1/863 subtests failed. SUKRIA/Dancer2-0.03.tar.gz ./Build test -- NOT OK Other tests are successful. I am using Debian 7.0 wheezy Raman.P -- blog:http://ramanchennai.wordpress.com/

1 0

Dancer vs Mojolicous
by igor.bujna＠post.cz 16 Mar '13

16 Mar '13

Hi, i don't want to start flame, but only ask when I make any project, why do I should choose Dancer instead Mojo*. Thank you for yours answer. " "

4 4

Dancer2::Test appears to misbehave
by Jashank Jeremy 12 Mar '13

12 Mar '13

G'day, I asked this on IRC, but I've not seen a response yet: If we have a very simple Dancer 2 application, consisting of the single route: get '/' => sub { "test reference 1"; }; If, then, Dancer2::Test is set up (in a separate package) and we call `response_content_is` response_content_is ([GET => '/'], "test reference 1"); the test does not pass: it _always_ fails, for reasons I don't quite grasp. If I turn on `DANCER_DEBUG_CORE` in the environment, it's obvious that the app is being configured correctly, and in fact, if we were to simply tell the application to dance, it would. This suggests, to me, that the bug is somewhere in Dancer2::Core. But I have no idea what the flow of routes and requests is, so I cannot (yet) suggest a solution. In the meantime, it looks suspiciously like Dancer2::Test is broken. I ran the Dancer2 test suite, which includes tests for Dancer2::Test, and, while it doesn't find any errors, I'm not convinced that the test code tests Dancer2::Test correctly. I'm not entirely sure how to proceed from here. Certainly, I'd like to know why `response_content_is` isn't actually handling responses correctly except in the test suite code, which suggests that it's a property of the way the routes are constructed in the test code -- and that really isn't helpful. I've got the full code and essentially all of these notes up on Github at https://gist.github.com/Jashank/5140883 Cheers, Jashank -- Jashank Jeremy PGP: 0x25A5C309

2 2

Accessing config in the templates
by Octavian Rasnita 12 Mar '13

12 Mar '13

Hi, I was sure the config hash is accessible in the templates, but I found that it is not. Then I read: "note that for convenience, the request, session, params and vars are automatically accessible in the view, named "request", "session", "params" and "vars" I think it could be useful if the config would be also accessible. Or is there a reason this would not be a good idea? --Octavian

4 4

Dancer2::Plugin::Database missing?
by Octavian Rasnita 12 Mar '13

12 Mar '13

Hi, In Dancer2::Cookbook I read that there is a module Dancer2::Plugin::Database which can be used to access a database. I clicked on that link but I've seen that there is not such a module. Is there a better way of accessing a database directly than by using this module? (without using an ORM) --Octavian

5 6

How to use Dancer::Plugin::Async?
by chenlin rao 12 Mar '13

12 Mar '13

The code in 'SYNOPSIS' cannot run correctly. the 'curl localhost:3000/timer' command return nothing immediately. Is there anyone use this plugin?

1 0

Still an error when using a WRAPPER
by Octavian Rasnita 12 Mar '13

12 Mar '13

I found that Dancer2 can accept the WRAPPER directive in a TT template, but if the file name of the wrapper is wrapper.tt, it still gives the error: Internal Server Error file error - parse error - E:\web\mdw\views\index.tt line 1: unexpected token (WRAPPER) [% WRAPPER wrapper.tt %] If I change the name of the wrapper file with something else, for example test.tt and use [% WRAPPER test.tt %] then it works fine. Strange. --Octavian

2 2