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

dancer2's prototype is there, feedback needed
by sukria 05 Oct '12

05 Oct '12

Hi there, I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised. -*- https://github.com/sukria/dancer2 -*- dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes: - no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...) The prototype I've pushed to GitHub currently covers ~80% of the DSL of Dancer. It's able to run simple applications (it can run the PerlDancer.org website for instance). Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests. You can test very easily your app with dancer2: $ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl Also, important to know: most of the plugins may not be working well. Thanks a lot ;)

14 29

Re: [Dancer-users] params for post route not working
by David Precious 05 Mar '12

05 Mar '12

On Mon, 20 Feb 2012 18:33:11 +0000 GJ <gj(a)freeshell.org> wrote: > On Mon, Feb 20, 2012 at 10:54:04AM +0000, David Precious wrote: > > On Sun, 19 Feb 2012 23:20:48 +0000 > > GJ <gj(a)freeshell.org> wrote: > > > The above example is from the documentation, the result is the > > > `else' redirection. I tried my own code also. params->user is > > > empty, in fact if I dump all `params' its empty. > > > > Interesting. Can you dump the request object returned by the > > 'request' keyword so we can see what Dancer got? > > > $VAR1 = bless( { > '_read_position' => 0, > 'content_length' => '27', > 'connection' => 'keep-alive', > 'headers' => bless( { > 'user-agent' => 'Mozilla/5.0 > (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1', > 'connection' => 'keep-alive', 'accept' => > 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', > 'accept-language' => 'en-us,en;q=0.5', 'cookie' => > 'session=5aa3a19de3fdd444d66a0ff1a799cc721a0d72a0; user_name=admin; > dancer.session=empty', 'accept-encoding' => 'gzip, deflate', > 'content-length' => '27', 'host' => 'localhost', > 'accept-charset' => > 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'content-type' => > 'application/x-www-form-urlencoded', 'referer' => > 'http://localhost/login' }, 'HTTP::Headers' ), > '_http_body' => bless( { > 'content_length' => '27', > 'tmpdir' => '/tmp', > 'buffer' => '', > 'state' => 'buffering', > 'chunk_buffer' => '', > 'body' => undef, > 'content_type' => > 'application/x-www-form-urlencoded', 'length' => 0, > 'chunked' => '', > 'upload' => {}, > 'param_order' => [], > 'param' => {}, > 'cleanup' => 1 > }, 'HTTP::Body::UrlEncoded' ), > '_route_pattern' => '/login', > 'accept_encoding' => 'gzip, deflate', > '_route_params' => {}, > 'is_forward' => 0, > 'uploads' => {}, > '_body_params' => $VAR1->{'_http_body'}{'param'}, > 'body' => '', > 'accept_charset' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', > 'method' => 'POST', > 'id' => 1, <snipped rest> Hmm. It looks like the HTTP body contains content, but presumably hasn't been parsed yet. Are you able to test against Perlover's pull request: https://github.com/sukria/Dancer/pull/702 I'd be interested to know if that helps or not. From the dump above, it looks like the HTTP headers have been parsed already, so I'm not convinced it should make any difference. You said in another mail that this only happens when you run via Apache, not running stand-alone I believe; can you share the Apache config you're using so I can attempt to reproduce the problem? 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

3 4

raising exceptions in hooks.
by Rusty Conover 29 Feb '12

29 Feb '12

Hi Everyone, I'm trying to use a hook like: register_exception('DatabaseProblem', message_pattern => "Database problem: %s"); hook 'database_error' => sub { my $message = Carp::longmess($_[0]); my $handle = shift; raise DatabaseProblem => $message; return; }; This is documented in Dancer::Plugin::Database. To raise a DatabaseProblem exception in the event of a database error such as: my $dbh = database(); try { $dbh->do("insert into table_that_does_not_exist values(?)", undef, "yes"); } catch { my ($exception) = @_; if ($exception->does('DatabaseProblem') { # do something } }; The problem I'm getting is: An error occured while executing the filter named database_error: It seems we can't raise an exception in the database_error hook or any hook really, without having it generate a 500 error because Dancer::Hook catches all exceptions thrown in hooks and halts rendering. Relevant excerpt from Hook.pm: my $compiled_filter = sub { my @arguments = @_; return if Dancer::SharedData->response->halted; my $app = Dancer::App->current(); return unless $properties->should_run_this_app($app->name); Dancer::Logger::core( "entering " . $hook_name . " hook" ); try { $code->(@arguments) } catch { my ($exception) = @_; # exception is not a workflow continuation but a genuine error my $err = Dancer::Error->new( code => 500, title => $hook_name . ' filter error', message => "An error occured while executing the filter named $hook_name: $exception", exception => $exception, ); # raise a new halt exception Dancer::halt( $err->render ); }; }; Can we change this so exceptions can be raised from hooks, or is there another pattern I should be using to catch DBI errors? Many thanks, Rusty -- InfoGears Inc. http://www.infogears.com http://www.gearbuyer.com

2 2

Can't locate object method "new" via package "Dancer::Exception::Core::Request"
by Puneet Kishor 25 Feb '12

25 Feb '12

I added a `debug` to my app and now I am getting the following with the latest version of Dancer Can't locate object method "new" via package "Dancer::Exception::Core::Request" (perhaps you forgot to load "Dancer::Exception::Core::Request"?) at /opt/local/lib/perl5/site_perl/5.14.1/Dancer/Exception.pm line 64. /opt/local/lib/perl5/site_perl/5.14.1/Dancer/Exception.pm around line 64 61 $exception = $exception_name->new(@_); 62 } else { 63 _camelize($exception_name); 64 $exception = "Dancer::Exception::$exception_name"->new(@_); 65 } 66 $exception->throw(); Any idea why? -- Puneet Kishor

2 2

Dancer::Plugin::SQLSearch
by Julio Fraire 22 Feb '12

22 Feb '12

Hola amigos! I have uploaded Dancer::Plugin::SQLSearch to CPAN, which is aimed to help with the creation of simple search pages. Basically, it will take a search query and turn it into a data structure suitable for SQL::Abstract. You then supply a subroutine that takes this data structure and performs the actual search in your database. >From the plugin (and your search routine) you get the first page of results and information to build pagination links. It also saves some info in the session object to offer "back to search results" links for your destination pages. Hopefully the documentation is clear enough for you to play with this little plugin; the tests should offer some insight as well. I hope you find it useful. Happy new year, Julio Fraire

7 9

params for post route not working
by GJ 21 Feb '12

21 Feb '12

Hi all, I am using Dancer 1.3092 . I can't access or use params for post routes, eg ---- post '/login' => sub { # Validate the username and password they supplied if (params->{user} eq 'bob' && params->{pass} eq 'a') { session user => params->{user}; redirect params->{path} || '/'; } else { redirect '/login?failed=1'; } }; ---- The above example is from the documentation, the result is the `else' redirection. I tried my own code also. params->user is empty, in fact if I dump all `params' its empty. I also tried `$user = param "user"' and every other thing I could find in the docs, and it is the same result, nothing. Is there something I need to set? My config.yml is as follows: ---- appname: "My::App" # The default layout to use for your application (located in # views/layouts/main.tt) layout: "main" # when the charset is set to UTF-8 Dancer will handle for you # all the magic of encoding and decoding. You should not care # about unicode within your app when this setting is set (recommended). charset: "UTF-8" #template: "simple" template: "html_template" engines: HtmlTemplate: loop_context_vars: '1' global_vars: '1' session: "cookie" session_cookie_key: "xxxx" plugins: Database: driver: 'mysql' database: 'xxxx' host: 'localhost' username: 'xxxx' password: 'xxxx' ---- Any help would be appreciated. Regards, GJ

4 6

Re: [Dancer-users] params for post route not working
by GJ 20 Feb '12

20 Feb '12

On Mon, Feb 20, 2012 at 12:46:36PM +0100, Perlover wrote: > Hello, > > I think this problem can be related with this my pull request: > > https://github.com/sukria/Dancer/pull/702 > > This pull request is not realized but from this bug the Dancer cannot > get HTTP Headers under PSGI invocation (for example under Starman). > A POST requests use a HTTP Headers for param getting and if http > headers are empty request object can return undefined POST parameters Thanks. I'm not totally clear on how all this PSGI and Plack business works, but I think the issue is not PSGI, but with any server besides the built-in one. My problem, as I reported it, was under Apache -- but when I read your email, I decided to switch to the built in webserver launched by bin/app.pl, and then my problem goes away! Of course, I need to run under Apache in production, so the issue remains acute for me. Regards GJ

1 0

Feeding options to Dancer::Template::HtmlTemplate
by GJ 19 Feb '12

19 Feb '12

Hi all, I am migrating a vanilla CGI application that relies on HTML::Template to dancer, and so of course I will use the Dancer::Template::HtmlTemplate library for now. Where do I feed my usual HTML::Template options like loop_context_vars, global_vars, and so on to the plugin? The source code indicates that there is a %{$self->config} that is passed on to HTML::Template, but its not clear to me when to fill this out. I'm very much learning as I go, so I apologize if this covered somewhere in the documentation that I missed. Thanks! GJ

2 2

What's my route handler?
by David Cantrell 15 Feb '12

15 Feb '12

I have some fairly complex user authentication to do - users can be in multiple groups, users in certain groups can legitimately access certain URLs but not others. I've got login working nicely, mostly cribbed from the cookbook, but am now trying to figure out a nice way of handling the different authentication requirements for my different routes. For example, if I am a mafioso I might have these routes ... get '/billing' => sub { ... }; get '/killing' => sub { ... }; Users in the 'Accountants' group should be able to access /billing, but only users in the 'Hitmen' group should be able to access /killing. Of course, the big bad boss should be able to access both. Putting users into groups is trivial, and I already have a 'before' hook that checks that a user is logged in. But what I'd really like to do, in the interests of making it dead simple to add routes later and minimise the places where I have to write authentication code, is to extend that hook so that it can look at the subroutine attributes on the route handlers and compare those to the user's groups: get '/billing' => sub :CapoFamiglia :Accountants { ... }; get '/killing' => sub :CapoFamiglia :Hitmen { ... }; So, my question is ... how can I get at those subroutine references from inside my 'before' hook so that I can attributes::get($route_handler) ? -- David Cantrell | Reality Engineer, Ministry of Information

3 6

Re: [Dancer-users] What's my route handler?
by David Cantrell 15 Feb '12

15 Feb '12

On Wed, Feb 15, 2012 at 10:40:36AM -0600, Franklin Bristow wrote: > While I haven't actually used it personally (my app doesn't require roles), > I think that Dancer::Plugin::Auth::RBAC ( > http://search.cpan.org/dist/Dancer-Plugin-Auth-RBAC/) does what you're > hoping to achieve. It appears that that needs to be told explicitly when you try to authenticate what it is that the user is trying to do, and so either the call to the authentication code needs to be done inside the route handler (cos that's what knows what the user is trying to do, but this is unnecessary duplication of code), or if I use a 'before' hook, the hook needs to be able to figure that out from the URL (which is also unnecessary duplication of code). Hence why I thought of using subroutine attributes on the route handlers. Once I've got a list of those subroutine attributes, I could well end up using that plugin to do the actual authentication. -- David Cantrell | London Perl Mongers Deputy Chief Heretic You can't spell "slaughter" without "laughter"

1 0