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

Re: [Dancer-users] Private template in Dancer
by Alexis Sukrieh 30 Jun '10

30 Jun '10

[ add dancer-users(a)perldancer.org in CC ] Le 15/06/2010 09:14, igor.bujna(a)post.cz a écrit : > > Hello, Hello, First of all, please post this kind of question directly to the users mailing list, that way more people give attention to your problem and the better the support you get. > sory for my bad english first. > I try yours super framework and for me is missing than global vars for template. > I wanna defined something in before{} func and this will be in every template. > Forr me is simplest show how i use. > I call this as 'private_template' and its must be vars like that: > > set private_template => '1'; > before sub { > var private_template => { > test => "Hello world", > }; > }; > > I must make this patch for Dancer/Helper.pm > --- Dancer/Helpers.pm~ 2010-06-09 22:37:44.000000000 +0200 > +++ Dancer/Helpers.pm 2010-06-10 21:53:29.000000000 +0200 > @@ -54,6 +54,12 @@ > $tokens->{session} = Dancer::Session->get; > } > > + my $pt = exists($options->{'private_template'}) > + ? $options->{'private_template'} : setting('private_template'); > + if ($pt) { > + $tokens->{private} = > Dancer::SharedData->vars->{'private_template'}; > + } > + > my $content = Dancer::Template->engine->render($view, $tokens); > return $content if not defined $layout; > > ------------------------------------------------------------------------------------------------------------------------------------------- > Now in every template i can use this variables via 'private' call. > It must be enabled for every template via set private_template => '1' > Or can enabled or disabled separately in options 'private_template' in given > using template. > > It would be good to make something similar in this framework. > > Thank you and make dance Igor Bujna > Well, Franck Cuny has been rewriting a lot our template engiens recently and I'd like to have his point of view on this. My first opinion is that using settings for private template variables is not a good idea. Setting should remain.... setting ;) We also had in mind to provide a new kind of hook, called "before_template" which could process variables before any template is called. So I suppose we should wait for feedback from the team first. Regards, -- Alexis Sukrieh

3 3

If you need some testing about dancer on WinOS
by sebastien deseille 30 Jun '10

30 Jun '10

Hello I work a lot on WinOS if you need some testing in this OS about dancer I'm available. -- regards Sebastien Deseille

1 0

First Dancer drinkup meeting
by franck cuny 29 Jun '10

29 Jun '10

Hi all, As discussed with alexis, we want to organize a first drinkup meeting for Dancer's users and developpers in Paris the first of july. The idea is to meet in a pub, bring a laptop, and code/talk/share ideas. So if you're a user/contributor to dancer, or interested in web development with Perl (Plack!), please reply to the list so we can organize and decide a location :) -- Franck Cuny - http://lumberjaph.net GPG keyid: 0x1A6B0C28 - http://pgp.mit.edu/ "no rain but thunder, and the sound of giants ..."

6 5

Uploaded files: what is their life-cycle?
by Daniel Pittman 16 Jun '10

16 Jun '10

G'day. I have been looking at the life of uploaded files in Dancer, since I need to perform a multi-stage interaction with my users while importing data from an Excel spreadsheet.[1] Anyway, as far as I can tell the default Dancer instance with 'load_app foo; start;' never deletes an uploaded temporary file. They just like on disk forever. So, I wondered: what is the life-cycle of them? Who should be deleting these files: - the underlying Plack (or internal) application server? - the HTTP::Body instance used by the Dancer core? - the Dancer core? - my application? My concern here is that none of them actually /do/ take responsibility for that, so right now anyone can fill the temporary space on my application server by sending requests to Dancer with files — ouch. FWIW, my personal preference would be that the Dancer core magically made this work, by ensuring that the files got deleted at the end of the request. Given that you can't robustly rely on storage within a single application server under Dancer[2], this makes the most sense — anyone who cares about that content will have arranged for it to persist during the request. Attached is the obvious, trivial, one-line patch that implements that, by telling the HTTP::Body instance to delete temporary files when destroyed. Daniel Footnotes: [1] Don't ask. It isn't really a choice. [2] ...because anyone could attach you to, say, a FastCGI Plack instance that forks multiple children, and you wouldn't even know until your application broke horribly. -- ✣ Daniel Pittman ✉ daniel(a)rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons

2 2

Dancer::Plugin::Database new features - dbi_params and on_connect_do settings
by David Precious 15 Jun '10

15 Jun '10

Just FYI, version 0.06 of Dancer::Plugin::Database has just been released, incorporating two new features, courtesy of Igor Bujna - thanks Igor! The changes are: * the ability to provide parameters to be passed to the DBI->connect call, e.g. RaiseError or AutoCommit * the ability to provide a list of queries which should be performed immediately upon connection to the database. An example configuration block, showing the new dbi_params and on_connect_do settings in use, is: plugins: Database: driver: 'mysql' database: 'test' host: 'localhost' username: 'myusername' password: 'mypassword' connectivity-check-threshold: 10 dbi_params: RaiseError: 1 AutoCommit: 1 on_connect_do: ["SET NAMES 'utf8'", "SET CHARACTER SET 'utf8'" ] Cheers Dave P -- David Precious <davidp(a)preshweb.co.uk> http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)

1 0

Re: [Dancer-users] (proposal) Re: Routes with captures
by Marc Chantreux 02 Jun '10

02 Jun '10

On Wed, Jun 02, 2010 at 12:28:50AM +0300, sawyer x wrote: > Good job Marc! :) I did it in less than an evening thanks to your (all Dancer programmers) awesome job writing a neat framework with a clean internal. thanks to you all! BTW: i finally vote for route_paren marc

2 2

Re: [Dancer-users] Routes with captures
by Marc Chantreux 01 Jun '10

01 Jun '10

hello, > - r() already supports full regex patterns (perhaps without special extras such > as "/x" but that can be, I believe, patched.) it does! i wrote any [qw| post get |] , r( qr( / ([^/]+) # the class / ([^/]+) # the object / ([^/]+) # the action /?$ )x ) , sub { "Yeah" } and it worked! and then i was confused because the r() became useless noise. > r('/.+/\w+_\w/'); > is easier and more readable than: > qr/\/.+\/\w+_\w\//; > > It's true - however - that we could try and encourage a bit more readable regex > patters: > qr{/.+/\w+_\w/} > Still, readability suffers. qr(/.+/\w+_\w/); r('/.+/\w+_\w/'); Both are readable for me. > However, there are certain benefits to discuss and perhaps we'll add your > patched. Since it's not something so trivial, a discussion will ensue. :) Ok so i try to sell my point of view :) * r('') is code to maintain :-) * i really agreed your concern about readability but i don't understand why qr() is harder to read than r(''). I think qr() could be more readable in large applications: r('') does not use /x for the moment. as /x is a very good practice that is: - recommended in the "Perl Best Practice" - defaut behavior in perl6 - very addictive for those whom still use it so i think qr( / ( borrower | book | shelf ) # Bizness objects / ( delete | create ) # Crud actions / ( \d+ ) # id ) is way easier to maintain than r('/(borrower|book|shelf)/(delete|create)/(\d+)') About the feature proposed in my former message: qr( / (?<class> borrower | book | shelf ) # Bizness objects / (?<action> delete | create ) # Crud actions / (?<id> \d+ ) # id ) , sub { splat->{capture}->{action} } In the current Dancer behavior, you'll write '/:class/:action/:id' seems easier but: - you have to test all the captures in the code, which i think is a big readability issue: unless ( my ( $action = splat->{action} ) ~~ [qw/ delete create/] ) { not_found("$action isn't a valid action"); } - you'll match tons of urls too soon so it could be very hard to write smart dispatcher. for exemple, i think '/:class/:action/:id' can't be splitted in 2 rules like this get qr( / (?<class> program | library ) / (?<action> test | make ) / (?<id> \d+ ) )x, sub { "rule 1" }; get qr( / (?<class> documentation | tickets ) / (?<action> publish | alert ) / (?<id> \d+ ) )x, sub { "rule 2" } Finally, and even i prefer the qr() approach, i don't see why both syntaxes can't cohabitate in Dancer. regards, marc

3 10

Dancer on shared hosting
by Patrick Donelan 01 Jun '10

01 Jun '10

Hi Dancer people, I was playing with Dancer today, trying to work out the right recipe to get it running smoothly on a shared hosting account (documented here<http://perlsharedhosting.com/tech/dancer> ). I started with trying to get Dancer running in CGI mode, but for some reason I could get it to accept requests to '/', e.g. http://domain/dispatch.cgi/ Whenever I request that, it returns the contents of dispatch.cgi, even with the default route changed to r('.*'). Whereas requests to /dispatch.cgi/blah work fine. Sounds like an Apache problem right? The bizarre thing is that other simple plack CGI scripts work fine, and if I actually put a Data::Dumper::Dumper($env) into app.psgi, it actually dumps out the env hash (before returning the contents of dispatch.cgi), which seems to indicate it's actually running the script, but then bailing out or something. In case it helps, the dumped contents of $env are: *{ 'psgi.multiprocess' => 1, 'SCRIPT_NAME' => '/dispatch.cgi', 'PATH_INFO' => '/', 'HTTP_ACCEPT' => 'application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5', 'REQUEST_METHOD' => 'GET', 'PERL_MM_OPT' => 'INSTALL_BASE=/home1/muscleca/perl5', 'psgi.multithread' => 0, 'SCRIPT_FILENAME' => '/home1/muscleca/public_html/perlsharedhosting/dispatch.cgi', 'SERVER_SOFTWARE' => 'Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635', 'PLACK_ENV' => 'development', 'HTTP_USER_AGENT' => 'Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4', 'REMOTE_PORT' => '50243', 'QUERY_STRING' => '', 'HTTP_PRAGMA' => 'no-cache', 'SERVER_SIGNATURE' => '<address>Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635 Server at hostmonster.perlsharedhosting.com Port 80</address> ', 'HTTP_CACHE_CONTROL' => 'no-cache', 'HTTP_ACCEPT_LANGUAGE' => 'en-US,en;q=0.8', 'psgi.streaming' => 1, 'PERL5LIB' => '/home1/muscleca/perl5/lib/perl5:/home1/muscleca/perl5/lib/perl5/x86_64-linux-thread-multi', 'PATH' => '/home1/muscleca/perl5/bin:/usr/local/bin:/usr/bin:/bin', 'GATEWAY_INTERFACE' => 'CGI/1.1', 'psgi.version' => [ 1, 1 ], 'DOCUMENT_ROOT' => '/home1/muscleca/public_html/perlsharedhosting', 'psgi.run_once' => 1, 'PATH_TRANSLATED' => '/home1/muscleca/public_html/perlsharedhosting/dispatch.cgi/', 'MODULEBUILDRC' => '/home1/muscleca/perl5/.modulebuildrc', 'UNIQUE_ID' => 'TASHmkrc13MAAGkor0AAAAnZ', 'SERVER_NAME' => 'hostmonster.perlsharedhosting.com', 'HTTP_ACCEPT_ENCODING' => 'gzip,deflate,sdch', 'SERVER_ADMIN' => 'webmaster(a)perlsharedhosting.musclecarwebdesign.com', 'HTTP_CONNECTION' => 'keep-alive', 'HTTP_ACCEPT_CHARSET' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.3', 'SERVER_PORT' => '80', 'HTTP_COOKIE' => '__utmz=226470915.1275355275.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=226470915.680138832.1275355275.1275355275.1275357426.2; __utmc=226470915', 'REMOTE_ADDR' => '96.232.149.145', 'SERVER_PROTOCOL' => 'HTTP/1.1', 'psgi.errors' => *::STDERR, 'REQUEST_URI' => '/', 'psgi.nonblocking' => 1, 'SERVER_ADDR' => '74.220.207.74', 'psgi.url_scheme' => 'http', 'HTTP_HOST' => 'hostmonster.perlsharedhosting.com', 'psgi.input' => *::STDIN };* Thanks, Patrick

1 1