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

Accessing template vars in layout
by Olaf Alders 16 May '10

16 May '10

Hi All, I'm totally new to Dancer, but I did manage to set up a Dancer app in no time at all last week, which is great. My config.yml looks like this: layout: "main" logger: "file" auto_page: 1 template: template_toolkit engines: template_toolkit: start_tag: '[%' stop_tag: '%]' INTERPOLATE: 1 With this setup, I wasn't able to make TT variables which I set in the various templates available in the layout. Am I missing something? I did a fair amount of digging, but I couldn't figure it out. Any tips are appreciated. Thanks, Olaf -- Olaf Alders olaf(a)wundersolutions.com http://www.wundersolutions.com http://twitter.com/wundercounter 866 503 2204 (Toll free - North America) 416 944 8306 (direct)

3 3

Dancer 1.18 released!
by Alexis Sukrieh 16 May '10

16 May '10

Hi, I'm glad to announce the release of Dancer 1.18 on CPAN: http://search.cpan.org/~sukria/Dancer-1.1800/ This new stable release is a major upgrade since the last one (1.176) as it's a full merge of the "devel" branch into the "master" one. You'll find lots of new features and bug fixes, as mentioned in the CHANGES file: Dancer 1.18 * Errors are caught in before filters * halt can be given a Dancer::Response object rahter than plain text content * New logger for sending log message to STDERR: Dancer::Logger::Console Thanks to Gabor Szabo for the idea. * Logger engines don't have anymore to implement _format(), they can use $self->format_message instead. * New log level: "core" for letting Dancer's core express itself on crucial events. That way, when the app config sets log to "core", any core messages is sent to the logger, and the end-user can see which route is chosen for each request received. Thanks to Gabor Szabo for the idea. * New class Dancer::Timer added so any logger engine can now show a timer string. * Scaffolded applications are now built like a CPAN distribution, with a Makefile.PL and test scripts (thanks to Gabor Szabo for the idea). * Added Dancer::Test to provide helpers for writing test script for Dancer applications * FIX bug when returning a void context after redirecting a route. Thanks to Juan J. MartÃnez for the report. * Add support for request headers in Dancer::Request * Add support for halt() in Dancer's syntax. * Support for on-the-fly charset encoding when the setting is set and a content is sent by Dancer and needs to be encoded. The response Content-Type is updated accordingly as well. * Adding "import_warnings" settings. On by default, but allows to disable auto-import of "warnings" pragma. Reported by Adam Kennedy. Enjoy your dances ;) -- Alexis, for the development team

1 0

Can't override appdir on import?
by Gavin Carr 13 May '10

13 May '10

Messing around with my first dancer app, so I'm a newbie. I'm using a non-standard layout (I want my dancer app in the 'bin' subdirectory, as it's only a small part of a bigger picture), but I can't find a way to override appdir at Dancer::import time? I can set it post-import via 'set appdir => X', and that works for most things, but it doesn't at least for logging, where logdir is set from appdir at import time (to the default). Is there a way of overriding this at import time? If not, should there be? Is a DANCER_APPDIR environment variable an option? Cheers, Gavin

1 0

Re: [Dancer-users] Dancer: allow multiple folders for Template's INCLUDE_PATH
by Alexis Sukrieh 30 Apr '10

30 Apr '10

[CC'ing the list / please, send this kind of messages to the list next times, thanks] Stéphane a écrit : > It would be nice to be able to specify multiple folders for > setting('views'), but that would require some extensive changes > (changing template() is simple enough, but a lot of spots in Dancer's > code assume 'views' is a scalar, not an array). Well, this doesn't fit the convetions Dancer is based on, I'm not sure why you want to do that (you can still create multiple directories inside the 'views' dir). > Would it be possible however to allow Template's INCLUDE_PATH to be > specified in the regular manner (using the "template_toolkit" engine > YAML configuration) and Dancer's default path to be pre-pended? Yes, this is a good idea, more generally, any TT config given in the configuration should be used prior to Dancer's defaults. > E.g. replace > > $tt_config->{INCLUDE_PATH} = setting('views'); > > in Dancer::Template::TemplateToolkit with: > > if($tt_config->{INCLUDE_PATH}) { > if(ref($tt_config->{INCLUDE_PATH}) eq 'ARRAY') { > unshift @{$tt_config->{INCLUDE_PATH}}, setting('views'); > } else { > $tt_config->{INCLUDE_PATH} = > [setting('views'),$tt_config->{INCLUDE_PATH}]; > } > } else { > $tt_config->{INCLUDE_PATH} = setting('views'); > } Hmm, no. There are different things you're talking about there: 1. the setting "views" which you want to be an ARRAY instead of a SCALAR. 2. the facility of changing TT's INCLUDE_PATH setting. I disagree with (1) for the reasons explained above. I agree with (2) but the user should be warned in some way that he might break something. Anyways, it's a sane idea to let them change whatever TT config they want via Dancer's engine config. If the user change the INCLUDE_PATH setting and don't include the "views" directory On the other hand, the "views" setting should remain a scalar to me, as this is one of Dancer's conventions: "views are located in a directory". > (I'm assuming that the paths will be specified in a YAML array if there > are more than one.) > > Again probably not a feature a lot of people are looking for, especially > if they deploy only once, but this allows me to separate generic views > from views that apply to a specific installation. To conclude, I think you should fill an issue report like "propagate all TT config entries from Dancer's configuration to TT's" so we can track the work on this more easily. Regards, -- Alexis Sukrieh

2 1

Problems loading an app
by Juan J. Martínez 27 Apr '10

27 Apr '10

Hello, Since I moved to the "load_app 'whatever';" scheme I've found that not all the errors are reported in the same way. When you try to run the application, sometimes you only get: unable to load application whatever at ../local/Dancer.pm line 155. I don't know if I'm doing something wrong, but it depends on the error: Example: missing a ; Bareword found where operator expected at path/lib/whatever.pm line 64, near "redirect" (Missing semicolon on previous line?) unable to load application whatever at ../local/Dancer.pm line 155. BUT, something like ($w doesn't exist): print "uh" if $user =~ m/$w/; Shows only the 'unable to load' message, but with "use whatever.pm" you get a more verbose message: Global symbol "$w" requires explicit package name at path/lib/whatever.pm line 62. Compilation failed in require at ./whatever.pl line 7. BEGIN failed--compilation aborted at ./whatever.pl line 7. Regards, Juanjo -- jjm's home: http://www.usebox.net/jjm/ blackshell: http://blackshell.usebox.net/ ramble on: http://rambleon.usebox.net/

3 11

Re: [Dancer-users] Dancer.pm sets confdir too early
by Alexis Sukrieh 26 Apr '10

26 Apr '10

[ CC'ing the list ] Le lundi 26 avril 2010 à 15:50 +0200, Stéphane a écrit : > In latest git, Dancer.pm at line 148 does: > > setting confdir => $ENV{DANCER_CONFDIR} || setting('appdir'); > > however this overrides what Dancer::Config->load() (especially this > means init_confdir() never get a chance to run). > > > Basically I'd like to be able to do: > > use Dancer ':syntax'; > set confdir => MyApp::confdir; # e.g. /etc/myapp/config.yml > use Dancer; > > but currently this gets overriden by Dancer->import(). No, you can't do that. It has never been possible to set the confdir via the "set" keyword as Dancer needs to parse configuration files at import time. The only supported way for using a separate confdir is to use the DANCER_CONFDIR environment variable. If you're running with the standalone server, just run it like: $ DANCER_CONFDIR=/etc/myapp ./server.pl ... Or under Apache, use SetEnv to set DANCER_CONFDIR. Changing that specific setting within the application code is not possible because if we allow that, we can't parse the configuration at load time. Regards, -- Alexis Sukrieh

2 3

problem sending mail
by Naveed Massjouni 21 Apr '10

21 Apr '10

When I try to send mail from within a route, I get: error when closing pipe to sendmail: No child processes Trace begun at /usr/local/share/perl/5.10.0/Email/Sender/Transport/Sendmail.pm line 77 On line 77 of Sendmail.pm it is just closing a file handle: close $pipe or Email::Sender::Failure->throw("error when closing pipe to sendmail: $!"); The code I wrote that sends the mail is very simple and works from a standalone script: use Email::Sender::Simple; use Email::Simple; Email::Sender::Simple->send(Email::Simple->create( header => [ To => $to, From => $from, Subject => $subject, ], body => $body, )); I was just wondering if this was a bug in Dancer or if I'm doing something wrong. Thanks, Naveed

2 2

New plugins & template engine (Dancer::Plugin::Database, Dancer::Plugin::SiteMap, Dancer::Template::HtmlTemplate)
by David Precious 19 Apr '10

19 Apr '10

Hi all, Just a little heads-up to two new Dancer plugins released recently: Dancer::Plugin::Database - to make using database connections from Dancer apps nice and easy Dancer::Plugin::SiteMap - to produce sitemaps automatically And also a new template engine supported: Dancer::Template::HtmlTemplate, for using HTML::Template from Dancer apps. Cheers Dave P (bigpresh) -- 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

Logs directory
by Juan J. Martínez 17 Apr '10

17 Apr '10

Hello, I'm playing with 1.174 and I've found that the log it's managed inside lib/logs, but every time I launch the application, another logs/ directory is created with an empty development.log file. Since I've upgraded to 1.174 from GIT and ported my 'on going' application to the new layout (I love it, great work!), I don't know if it's my fault or it's a bug. Tell me your opinion, and I'll file a bug if needed. Cheers, Juanjo -- jjm's home: http://www.usebox.net/jjm/ blackshell: http://blackshell.usebox.net/ ramble on: http://rambleon.usebox.net/

2 3

deployment confusion
by Duncan Hutty 14 Apr '10

14 Apr '10

I'm looking to have nginx use Dancer to run a subsection of a website, but while I know how to use apache fairly well, I'm new to both nginx and Dancer. I've looked carefully at D::Deployment and nginx/PSGI/Plack docs and I confess to be a little confused as to where each part fits into the whole. I think I understand how to make nginx proxy for requests for the subsection using fastcgi: server { listen *:80; servername blah location / { root /var/www/html; index index.html } location /dancer { include fastcgi_params; fastcgi_pass unix:/var/run/dancer.sock; } } But that means that, unlike Apache, I need something else to create the socket, listen for requests, respond to the requests, etc. I think that could be a standalone plackup daemon: plackup -s FCGI --listen /var/run/dancer.sock --daemonize --nproc 5 --app /path/to/Dancer_App/app.psgi that would I then write my own initscript for. Is that: a) correct? b) considered to be an admirable, efficient way to run a small production server or is this more for a development environment? I think that instead of the plackup command, I could use Starman to do the same thing. I think my confusion is coming from the fact that there are so many possible ways to deploy and I don't have a good understanding of how fastcgi/psgi/plack all fit together. Perhaps I need some explication rather than merely instructions, although instructions would be a good start:) Duncan Hutty

3 2