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

Dancer::SessionFactory::Memcached released
by David Golden 10 Apr '14

10 Apr '14

It's amazing how little code is needed with Moo and the role. Mostly, it just delegates everything. https://github.com/dagolden/dancer-sessionfactory-memcached/blob/master/lib… David -- David Golden <xdg(a)xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg

2 2

CGI must DIE! .... or Dancer::Plugin::FakeCGI
by igor.bujna＠post.cz 26 Feb '13

26 Feb '13

Hi, first i want thanks to Sawyer X about his good presentation on YAPC about CGI must DIE! I find only this video http://www.youtube.com/watch?v=tu6_3 fZbWYw. I have couple of project which use CGI.pm. I thinking about how can i simply rewrite this to any MVC framework. Couple of years ago, ther isn;t exist any usable MVC framework and every of us use CGI or other similar functions for creating HTML pages. How SawyerX said, CGI must die. Because working on big project writed on CGI, than one time you will have to much problem to keep consistence of programs. Before couple years ago i must writed one CRM project in Perl and try to find which frameworkt can use for this. I play with CGI::Application, Gantry, Jifty, Mojo, Catalyst. Winner of this was Catalyst, but next i finded newer project - Dancer :) and try to made this project atop Dancer. For me Dancer was and for now is winner as Perl web framework. Because is small, simpliest and made everything what i need. Catalyst is powerfull but bigger. Now when i thinking how move my CGI projects to Dancer i finded couple of solutions( Catalyst::Controller::CGIBin, HTTP::Request::AsCGI, CGI::PSGI, CGI:: Emulate::PSGI) but none of this make everything what i need. Than i make Dancer::Plugin:: FakeCGI. http://search.cpan.org/~koceasy/Dancer-Plugin-FakeCGI-0.60/lib/ Dancer/Plugin/FakeCGI.pm This plugin made emulation of Mod_PERL for now in version 1. I choose this, because any of us which use CGI.pm we had to use a mod_perl funcionalities to make better programs runned atop CGI.pm. You look on examples directories and run bin/app.pl from this. When you have bigger project writed atop CGI.pm than you have big problem to rewriting this to anythink else. Rewriting use yours time, which can you spend to extended funcionalities. It can look like this: Web--->INPUT-->CGI project do something--->HTML contentt I try to emulated mod_perl behavior in Dancer::Plugin::FakeCGI. First emulated input parametters under mod-Perl and second is capture everything what CGI project print to STDOUT. If i hade this than can be simple make any changes or funcionalities in this CGI. For this i use mocking and this package http://search.cpan.org/~sukria/Test-TinyMocker-0.03/lib/Test/ TinyMocker.pm(I send simply patch to Alexis Sukrieh to extend his package to method mocked, which can return original mocked method, but he dosn't answer on my email)(http://search.cpan.org/%7Esukria/) Now if i have this functionalities, than i have simplies change fincionalities in CGI project. I can mocked any function and if CGI project run this function than i return what i need, simply example is /test_6 under examples directories or this example: sub test_file { my ($cgi_bin, $cgi, $url, $is_perl) = @_; return 1 if ($cgi =~ /^\./); # skip serving this file https://email. seznam.cz/#compose/30576 return 1 if ($cgi =~ /test.pl/); # skip serving this file if ($cgi eq "index.pl") { # own serving for given file any $url => sub { redirect "/index.sh"; }; return 1; } return 0; # default serving file } fake_cgi_bin(\&test_file, ["*.pl", "*.sh"], 1); # Read every files *.sh or *.pl and try to serve automaticaly if method test _file() return 0; There is couple of problem when use this plugin: 1) in CGI can't be any infinity loop such us CGI::Push.pm or other, because i use capturing STDOUT and after CGI program exited than i server this captured informations-HTML pages to client 2) Problem with fork|system() function under HTTP::Server::Simple - This server make bad openening file descriptor of STDOUT on child pid and open STDOUT as STDERR of parent pid. Solution for this is use plackup 3) better solution for capturing STDOUT under system call when is set capture to memory. 4) Don't use dancer under mod_perl in apache. because I emulated mod_perl funcionalities. Solution for this is use Apache as proxy and serving connection to plackup server. 5) Serving file is about 20-50% slowest than under Mod_perl when use Registry.pm, because CGI::Compile behaviour is as PerlRun.pm. Now i worked on similar behavior as Registry.pm. 6) memory usage us bigger than on mod_perl - solution for this is buy more memory :D My reasons is this will be good for simple migration from CGI to Dancer. Now you can simply run any CGI project under Dancer and make simple refactoring of this code. Bye Igor

1 0

Re: [dancer-users] Configuring Plack::Middleware::Expires
by Gurunandan Bhat 19 Feb '13

19 Feb '13

Sorry - I found my error - the second parameter in the options list must be 'content_type' not 'content-type' Thanks On Mon, Feb 18, 2013 at 7:28 PM, Gurunandan Bhat <bhat.gurunandan(a)gmail.com>wrote: > Hi, > > I am trying to configure Plack::Middleware::Expires and Deflater to add an > expires header and gzip with the following in my config.yml: > > plack_middlewares: > - > - Expires > - content-type > - > - image/gif > - image/jpeg > - expires > - access plus 1 day > - > - Deflater > > I find that while the Deflater middleware works correctly, the Expires > does not. Is there an error in my YAML syntax? I tried to parse the YAML > separately and I seem to get the correct options that Expires expects. > > Would appreciate your help, > > Thank you. > > >

1 0

Dancer 1 and Dancer 2, what we're going to do
by Alexis Sukrieh 18 Feb '13

18 Feb '13

http://www.sukria.net/fr/archives/2013/02/18/dancer-1-and-dancer-2-what-wer… Fellow Perl hackers, you who like to “dance“, read the following carefully for I have some interesting news for you. You probably know that we’ve frozen Dancer 1 development some time ago, when we decided to focus all the energy on Dancer 2. That was done with an idea in mind: get the most possible out of the D2 prototype. We had also the idea that D2 will at some point be able to replace D1. Entirely. It was a mistake. Actually a mistake that will lead to something that I believe is rather very good for the Dancer community, let me explain. Dancer 2 is a success on many fields: it’s entirely written with Moo, so it has a complete OO layer. The core encapsulates each app in a proper instance, ensuring no more app collisions will occur. All the non-deprecated keywords of the DSL provided by Dancer 1 are supported in Dancer 2. Some components are even better in D2 (look at the awesome session handling for instance) and the Moo layer behind the scene allows many great things for the future. Plugins can be migrated quite easily to support D1 and D2 at the same time. But there is one thing that won’t be possible: support engines in D1 and in D2 transparently. The reason is rather technical: in D1, an engine (logger, template, session) is a class that should be extended (in pure Perl 5 code). In D2, it’s a role that should be composed. Of course, the design is more rigid, and many things need to be changed for an engine to work under D2. The question was: should we spend energy on trying to support both? Should we provide a wrapper to allow easy migration? The consensus is no. We’ll do something else. There is out there a lot of real-life D1 applications. Most of them use engines that won’t work transparently under D2. Also the app-scoping can break things with some applications, if the app is decoupled in many packages. For that reason, I’m going to release Dancer 2 in its own namespace, and that will bring a lot of energy in both projects: Dancer 1 is at the same time unfrozen, development can continue there (as long as the features added are not something that would lead to a new Dancer 2!) Dancer 2 is released on CPAN and its ecosystem can rise Dancer 1 users are happy Dancer 2 users are happy Migrating an app becomes something under control. So, be prepared to see Dancer2 on CPAN pretty soon :) And by the way, we’ll choose a Dancer 1 maintainer, because I won’t have the time to handle both projects. Stay tuned! Cheers, Alexis.

3 5

Configuring Plack::Middleware::Expires
by Gurunandan Bhat 18 Feb '13

18 Feb '13

Hi, I am trying to configure Plack::Middleware::Expires and Deflater to add an expires header and gzip with the following in my config.yml: plack_middlewares: - - Expires - content-type - - image/gif - image/jpeg - expires - access plus 1 day - - Deflater I find that while the Deflater middleware works correctly, the Expires does not. Is there an error in my YAML syntax? I tried to parse the YAML separately and I seem to get the correct options that Expires expects. Would appreciate your help, Thank you.

1 0

Capture or redirect STDOUT
by igor.bujna＠post.cz 14 Feb '13

14 Feb '13

Hi, i want to capture STDOUT under my Dancer applications with package Capture:: Tiny. I have this simple Perl test: ---------------------------------------------------------------------------- ---------------------------- use Capture::Tiny; my ($stdout, $stderr, $exit) = Capture::Tiny::capture { system( "echo 'OK'"); }; print STDERR "Captured:$stdout\n"; ---------------------------------------------------------------------------- ---------------------------- Capturing STDOUT in this script is ok, but when i move to Dancer app, that this faill. System print command to STDERR and nothing is captured. ---------------------------------------------------------------------------- ---------------------------- package Test; use Dancer ':syntax'; use Capture::Tiny; our $VERSION = '0.1'; get '/' => sub { my ($stdout, $stderr, $exit) = Capture::Tiny::capture { system( "echo 'OK'"); }; print STDERR "Captired:$stdout\n"; template 'index'; }; true; ---------------------------------------------------------------------------- ---------------------------- Why or where system/fork redirect STDOUT to STDERR ? How can I capture this under dancer. Maybe it will be possible to change system() call to own function, where can use IPC::Open3, but how can i made it? Thank you for yours suggestion Igor

2 2

Dancer::Plugin::FlashMessage and Dancer2
by Julio Fraire 06 Feb '13

06 Feb '13

Hello, I am trying to port an application from Dancer1 to Dancer2, but I have not been able to make FlashMessage work. I took the code from github, from the branch topic/Dancer2 but several strange things happen when I include it. For starters, the before_template_render hook does not appear in the debug messages that show as the app initializes (with DANCER_CORE_DEBUG set) and it is never run. Most importantly, under some circumstances the app returns a new, fresh session loosing whatever was in the old one (which remains in disk, but the key is lost). I put the simplest code in https://gist.github.com/4710740. Note that it must be run with the topic/Dancer2 branch of FlashMessage. Try running /logout without logging in; a second session appears. Is this something that you can reproduce? Am I doing something wrong? Not the least, thank you all for such hard work on Dancer and the whole ecosystem. I use FlashMessage for the other little apps I've written and it works very nice. Julio Fraire

2 4

"halt" not setting content-type?
by Aaron Hall 03 Feb '13

03 Feb '13

Dancer 1.3110, Perl 5.10.1 (Debian stable), Apache 2.2.16, mod_fastcgi. When I call from a route: halt $some_html; I'm getting back the unrendered HTML as text/plain, not text/html. This only happens when I'm using mod_fastcgi (with FastCgiExternalServer). When I just run "./app.pl", I get my rendered text/html. When I run "plackup ./app.pl", I get text/html. This only happens from "halt". If I use "return", I get text/html. Am I doing something wrong? I did try looking through the Dancer source to see how this works. I am over my head at this point (not a programmer by trade), but I wonder if perhaps "halt" isn't setting the content-type on the response object it creates. I manually created a Dancer::Response object and called $response->content_type("text/html") on it, passed that to "halt", and got text/html. Of course, none of that explains why FastCGI does one thing and the built-in server does something else. I'm working around it by creating my own Dancer::Response objects. Is that what I should be doing? Thanks very much, Aaron -- Aaron Hall : I claim this planet in the name of Mars. ahall(a)vitaphone.net : Hmmm, isn't that lovely?

1 0