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

Template vars in the layout
by Robert Olson 01 Apr '10

01 Apr '10

Hi - Just getting started with Dancer, so this might be an obvious question. I would like to be able to put per-route information into the layout template (for instance, current-page flagging in a navigation box, or setting the page title). Since it appears the only variable that is settable in the layout template is "content", my guess is that to do what I want I would need to shift all of that stuff into the per-page templates (or into common templates that are included into the per-page templates). Am I reading this correctly? Thanks, --bob

3 7

Dancer 1.170 released
by Alexis Sukrieh 24 Mar '10

24 Mar '10

Hi list! I'm pleased to announce that Dancer 1.170 has just been uploaded to CPAN. You can already fetch the tarball from the official website: http://perldancer.org/downloads/Dancer-1.170.tar.gz The changelog for this release is the following: [ David Precious ] * Fixed bug with status keyword not converting aliases (e.g. 'not_found') to real usable status lines with valid HTTP codes. Thanks to P Kishor for reporting this on the dancer-users mailing list! * Accept end_tag as a synonym for stop_tag when configuring TemplateToolkit. Thanks to James Ronan for bringing this up. [ Sawyer X] * Route::Cache store_route = store_path, beefed up docs * Changed names of limits in settings * Added documentation for it in Dancer.pm * More documentation about Module::Refresh dependency (closes bug #48) * uri_for now accepts a boolean for not escaping URIs, and redirect calls uri_for with that boolean. (closes: bug #47) [ Alexis Sukrieh ] * Query string params are not dropped anymore when their value is 0. thanks to "Squeeks" for the report. (closes: bug #49) * Support for file uploads The Dancer::Request class provides a common interface to access file uploads. Syntactic sugar has been added to Dancer's as well (keyword 'upload'). (closes whish #36) [ Franck Cuny ] * Support for automatic serialization/deserialization Dancer is now able to serialize route handler's response in various format (JSON, YAML, XML); and can also deserialize request body when appropriate. (closes: wish #29) Thanks to all of the people involved with this release! Happy Dancing. -- Alexis, for the Dancer dev team http://perldancer.org/

1 0

Request for donation
by Alexis Sukrieh 23 Mar '10

23 Mar '10

Hi, The Dancer project started in august 2009, when I saw Sinatra[1] and thought Perl needed something like that. At first it was just a basic route disptacher, but soon people started to pay some attention to it, and contributors started showing up. At the time of this writing, Dancer is 8 months old and has more than 100 followers on GitHub[2], the project is more and more popular and still attracts new users. A domain name has been registered[3] and a mailing list has been created[4]. Almost all of the features we want for the 1.2 release are done and are heavily tested, we're quite happy with the overall quality of the code (more than 80% of the codebase is covered by the test suite). So what's next? Well, we want to give Dancer a better website, one with a professional-looking design. To do so, we don't have many options: Either we find a profesional web designer willing to offer his time to do it or we pay one. Facts are that web designers willing to work for free projects (for free) are very rare, and we'll end up with a satisfying result faster if we hire a web designer. Hence this email: if you like Dancer and use it, either personaly or professionaly here is a very good way to contribute to the project: Help us hire a professional designer, make a donation[5] and contribute to give Dancer a better look for the outside world. All donators will be listed in a credit page, with a link to their website if they provide it. Of course, if you are (or know) a good web designer willing to offer his/her time to build a new pro-looking design, feel free to contact us. Best regards, Alexis, for the Dancer development team. 1: http://www.sinatrarb.com 2: http://github.com/sukria/Dancer 3: http://perldancer.org 4: http://lists.perldancer.org/cgi-bin/listinfo/dancer-users 5: http://perldancer.org/donate

3 2

Re: [Dancer-users] Dancer and PostgreSQL
by Alexis Sukrieh 22 Mar '10

22 Mar '10

Le samedi 20 mars 2010 à 18:26 -0500, Joel Gratton a écrit : > Hi, I am wondering is it possible to use Dancer with PostgreSQL? > > Thanks > Joel Hi Joel, Dancer does not provide any database interface, so you can basically use any ORM/DBI you like within your application. Regards, -- Alexis Sukrieh

1 0

Server migrated
by Alexis Sukrieh 12 Mar '10

12 Mar '10

Hi, The server that hosts perldancer.org's services has been migrated. Everything looks to be working just fine, but please, let me know if you find something. Regards, BTW: yes, this message is also a test to make sure the mailing list still works as expected ;) -- Alexis Sukrieh

1 0

Dancer, Plack, plain old CGI and mod_rewrite
by icovnik 11 Mar '10

11 Mar '10

Hi, I'm trying to set up a simple app, but unfortunately, it should run as old CGI script under Apache on Linux. The CGI script is reachable via http://server/appdir/script.cgi. I have set appdir/.htaccess like this: RewriteEngine On RewriteRule ^(.*)$ script.cgi The RewriteRule should be probably something like this: RewriteRule ^(.*)$ script.cgi?$1 The script calls Dancer app via Plack, that part works. Dancer renders templates just fine. The only problem I have is that the request->{path} variable is allways set to "/appdir/script.cgi" so my routes don't work. Can you please point me to correct settings to be able to make the routes work? The routes looking like this: get '/apdir/script.cgi?/path/:param' => sub { ... } would be ok. Even better would be if there was some way to allways strip the beginning of the path "/apdir/script.cgi?" so I would be able to write just the interresting part "/path/:param". Please assume that I am unable to run the application under FCGI or mod_perl. The Dancer's http server works but I need to make it work on our server... so... as plain CGI. Thank you. ico

3 5

Server downtime scheduled
by Alexis Sukrieh 10 Mar '10

10 Mar '10

Hi there, The server where perldancer.org is hosted will be moved to a new datacenter today, in approximatively 4 hours. This will unfortunately lead to a downtime, which I hope, will be as low as possbile. I apologize for the upcoming inconvenience. Regards, -- Alexis Sukrieh

1 0

possible bug with status()
by P Kishor 09 Mar '10

09 Mar '10

at least while using Proxy, status 'not_found' returns the following header that the browser doesn't understand HTTP/1.0 not_found Content-Type: text/html X-Powered-By: Perl Dancer 1.160 Changing the code to return status 404 fixes the problem. -- Puneet Kishor

2 1

deploying multiple dancer websites on localhost with mod_proxy
by P Kishor 09 Mar '10

09 Mar '10

starting a new thread, for clarity sake. Is the following possible with mod_proxy (I have fudged the prompts below to illustrate my scenario)? On my laptop, with Apache ---------------------------------------- punkish ~/dance1$./dance1.pl >> Dancer server xxxxx listening on http://0.0.0.0:3000/ == Entering the development dance floor ... punkish ~/dance2$./dance2.pl >> Dancer server xxxxx listening on http://0.0.0.0:3001/ == Entering the development dance floor ... punkish ~/Documents/dance3$./dance3.pl >> Dancer server xxxxx listening on http://0.0.0.0:3002/ == Entering the development dance floor ... Then, from my browser http://localhost/dance1 http://localhost/dance2 http://localhost/dance3 -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================

3 6

developing many Dancer apps coexisting with Apache apps
by P Kishor 09 Mar '10

09 Mar '10

I have finally got everything working correctly (the status() bug still exists), and have typed up the following notes. Please feel free to add them to the Dancer Deployment.pod if you think they will be helpful to others. I spent a lot of time getting to this point, so I think these notes will be helpful to others. ----- Once we have downloaded Dancer, generated a project scaffolding, fired up dance.pl, and visited our website at http://localhost:3000/, we are faced with several decisions -- How am I going to serve this on my web server? Will I be able to have multiple Dancer-powered sites? How will this integrate with Apache? A typical web application developer is working on several applications on her development machine. If she is smart and lucky, her development machine is identical to her production server, so she doesn't have to second guess differences in modules, software versions and directory layouts. Still, there are a few differences. Under the Apache scenario, her web sites in development are stored on her computer under ~/Sites/app0 ~/Sites/app1 ~/Sites/app2 She is accessing her web sites on her development machine via URIs that look like http://localhost/app0 http://localhost/app1 http://localhost/app2 Apache is listening on the default port 80, and serving everything under ~/Sites as the DocumentRoot by simply adding $app_dir to http://localhost With the arrival of Dancer, the out-of-box model is different. For all purposes, dance.pl is the web server, and is listening on port 3000 by default. But, there cannot be multiple web servers on one port. So, she modifies the config file in each of her apps so she can fire up dance.pl in each of the apps, and have each one of them listen on different ports. Perhaps something like this app0 at http://localhost:3000/ app1 at http://localhost:3001/ app2 at http://localhost:3002/ Our developer wants to continue to serve some of her Apache apps as they are, but also experiment with a few new apps with Dancer, but access them without having to specify the different port numbers. The easiest way to accomplish this is via the Apache module mod_proxy. First, she enables mod_proxy in her httpd.conf. This is done by uncommenting the following lines in httpd.conf LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so If she is unlucky enough to not have the above modules available, then these modules will have to be compiled. Compiling mod_proxy and mod_proxy_http is out of the scope of this document. Now, she has to add the following proxy commands to httpd.conf ProxyRequests Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /app0/ http://localhost:3000/ ProxyPassReverse /app0/ http://localhost:3000/ ProxyPass /app1/ http://localhost:3001/ ProxyPassReverse /app1/ http://localhost:3001/ ProxyPass /app2/ http://localhost:3002/ ProxyPassReverse /app2/ http://localhost:3002/ The above command instruct Apache to take the listed URIs at http://localhost/ and query them on their respective ports. This allows our developer to point the browser to http://localhost/app0/, and actually get a response back from http://localhost:3000/ However, the above is not enough, because trying to get something from http://localhost/app0 will fail (notice the lack of the trailing slash). To make sure that http://localhost/app0 also work, another Apache module called mod_rewrite is required using the following commands in httpd.conf RewriteEngine on RewriteRule ^/app0$ app0/ [R] RewriteRule ^/app1$ app1/ [R] RewriteRule ^/app2$ app2/ [R] Restart Apache, fire up dance.pl under each of the different app directories, each listening on different ports, and enjoy the dances. A few important notes: Since the new Dancer-powered websites are not going to be served by Apache, they really shouldn't be kept under the ~/Sites path, because that is being served automatically by Apache by virtue of being Apache's DocumentRoot. It is ok to locate the dances under some other hierarchy outside of Apache's reach. I have mine under ~/Dances ~/Dances/app0 ~/Dances/app1 ~/Dances/app2 The new websites might mix resources, perhaps getting some JavaScript framework files being served from other computers, or perhaps even from a traditional Apache website at http://localhost/lib, but also have resources local to the apps under their own 'public' directories (Dancer allows browsers to access resources under the 'public' directory). This can be accomplished by having HTML in main.tt like so  <link rel="shortcut icon" href="favicon.ico" /> <link type="text/css" rel="stylesheet" href="css/styles.css" />  <script type="text/javascript" src="/lib/jquery/jquery-1.4.min.js"></script> <link type="text/css" rel="stylesheet" href="/lib/SyntaxHighlighter/Styles/shCore.css" /> <script type="text/javascript" src="/lib/SyntaxHighlighter/Scripts/shCore.js"></script> Final note: Once everything is working, the apps will be moved to the production server. The production server will not be serving stuff from http://localhost, but will have a real DNS name. This will be accomplished using VirtualHosts under Apache, whereby one can serve multiple websites from the same server. Dancer can continue to function as above, but the proxy commands will have to be moved to respective VirtualHosts sections. That story is for another time. -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================

2 2