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

entering before_template_render hook
by Nick Knutov 30 Aug '11

30 Aug '11

Hello all, use Dancer ':script'; ... my $comment = template ... ... [6703] core @0.000008> entering before_template_render hook in /usr/local/share/perl/5.10.1/Dancer/Hook.pm l. 57 Why this can occurs? How to disable this message? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130

2 1

New stable release: 1.3072
by Alexis Sukrieh 23 Aug '11

23 Aug '11

Hey fellow dancers! The Dancer Core Team is happy to announce the release of Dancer 1.3072, codename "Precious David Precious". This release provides more flexibility in send_file (send raw content), minor bug fixes and some documentation improvements. https://metacpan.org/release/XSAWYERX/Dancer-1.3072 This release has been prepared and shipped to CPAN by Sawyer X, it should hit your favorite mirror soon. The changelog delta since 1.3071 follows: [ BUG FIXES ] * Fix prefix behavior with load_app (alexrj) * send_file() shouldn't clobber previously-set response status (David Precious, reported by tylerdu - thanks!) * Depend on URI 1.59 - Fixes problems when redirecting with UTF-8 strings (Alberto Simões) * Fix before_serializer POD fix (Yanick Champoux) [ ENHANCEMENTS ] * send_file can send data (pass a reference to a scalar), and can specify a content-disposition filename. (Alberto Simões) * Set 'Server' HTTP response header as well as 'X-Powered-By'. For cases where Dancer is being accessed directly, or the proxy passes on this header, it's nice to see it. (David Precious) [ DOCUMENTATION ] * Cookbook links to canonical documentation of keywords in Dancer.pm, so readers encountering a new keyword can easily see the docs for it (David Precious) * Docs for debug/warning/error link to Dancer::Logger for details on how to control where logs go (David Precious) * Document import_warnings option, and mention it & link to that documentation in opportune places. * Document that 'get' also creates a route for 'HEAD' requests (David Precious, prompted by Matt S Trout) * Extend request() keyword docs with examples (David Precious) * Correct port in Lighty/FCGI example in Dancer::Deployment (David Precious, thanks to pwfraley in Issue 621) The next stable release will be 1.3080, as always we will first ship at least one RC as a DEVELOPER version (which will be 1.3079_02). Happy dancing! -- Alexis Sukrieh -+- Hackers gonna hack! “The problem with quotes on the Internet is that you can't always be sure of their authenticity.” -- Abraham Lincoln http://sukria.net http://twitter.com/sukria

2 1

Rejoindre mon réseau sur LinkedIn
by woosley xu via LinkedIn 22 Aug '11

22 Aug '11

LinkedIn ------------ woosley xu souhaite se connecter à vous sur LinkedIn : ------------------------------------------ Je vous invite à faire partie de mon réseau professionnel en ligne sur le site LinkedIn. Accepter l'invitation de woosley xu http://www.linkedin.com/e/-dmhwk6-grmsa8qq-8/XDTwb9U_Go0kODHjgNTbVSU_GX14lx… Voir l'invitation de woosley xu http://www.linkedin.com/e/-dmhwk6-grmsa8qq-8/XDTwb9U_Go0kODHjgNTbVSU_GX14lx… -- (c) 2011, LinkedIn Corporation

1 0

Feedback requested: streaming support
by sawyer x 20 Aug '11

20 Aug '11

Hey everyone, I've been working on a nice feature and I wanted to get some feedback from the community before it's merged. We want to merge this by the beginning of next week and release it, so *early feedback is important*. Don't let this linger for long. In short: skim though the email, check the examples, let me know if it makes sense. That is all. We've been asked several times for streaming support. While we're built on PSGI and that allows you to separate that part into another layer (outside of Dancer, but within the same server instance), people wanted to be able to do streaming from inside Dancer - which makes sense, obviously. Recently I've hacked on this and set up a new branch on the Dancer github repo: "feature/send_data_streaming". Right now it adds support for send_file() but I intend to refactor this out to another keyword. I have a few bells and whistles here but before I show it, I want to explain the type of feedback I'm interested in: 1. Is it useful for you? 2. Are the examples here helpful? Is the syntax understandable? 3. If not, what would be a more suitable syntax, in your opinion? 4. Are there enough features? Do you need more power, more options? 5. How are you doing today? Feel free to share. :) *The basics:* Basically I've added the ability to ask send_file() to send the file (or straight content, as send_file() supports a scalar ref as pure data to send to the user) streamingly. It uses the PSGI spec for this, so it's 100% compatible, no magic of any kind. You can ask it to be streamed using a simple flag: send_file( 'log.txt', streaming => 1 ); This will send the file one line at a time. This also works on scalar refs: send_file( \'my string to stream back', streaming => 1, ... ); *Method callbacks:* I wanted users to be able to control what happens before each line and after each line streamed. You can do that using method callbacks. These callbacks also get the line as a parameter so you can do stuff with it. send_file( 'log.txt', streaming => 1, before_cb => sub { my $line = shift; say "About to send a line: $line" }, after_cb => sub { my $line = shift; say "Just sent the line: $line" }, ); However, this wasn't enough for me. What if I don't want to stream one line at a time. What if it's a binary and I want to stream it 512K at a time? You're able to do that too. You can override the method that gets the content's file handle and you can control what happens: send_file( $binfile, streaming => 1, around_cb => sub { my $content_fh = shift; # now I can do whatever I want with it }, ); *Complete control:* Here's another thought. While we're at it, how about we allow people to take over the ENTIRE operation? We can do that, using a method override. Take into account you should understand how PSGI streaming works, but this means you can really go all out. send_file( $binfile, streaming => 1, override_cb => sub { my ( $respond, $response ) = @_; my $writer = $respond->( [ $newstatus, $newheaders ] ); $writer->write('some line'); }, ); This might seem scary. It is, a bit. Like I said, you should know what you're doing. And if you do - hell - you get ALL the control right there. Things to note: 1. I want to refactor out the logic so it will be available in another keyword, like "send_streaming(...)". Will that be useful for anyone? 2. This might mean that you won't need to use "override_cb". 3. Do the callback names make sense? 4. Would you prefer getting the original method inside the "around_cb"? Should an around_cb with the content be named differently? What do you suggest? 5. I intend to add nonblocking streaming which will allow to run a request, answer it and run other stuff at the same request call. 6. "Blocking streaming" doesn't block the server, just the specific request. Other requests aren't blocked. Apologies for a long mail and thanks in advanced to anyone answering. :) Have a great weekend, Sawyer.

4 7

Routing: captures in prefix
by Michele Beltrame 19 Aug '11

19 Aug '11

Hello! I'm just beginning with Dancer - looks like a great framework to me - and I have a question. I have the following code: ------------------ package stelage::products; use Dancer ':syntax'; get '/:lang/products/' => sub { return vars->{lang} . ' is the language'; }; ------------------ This works and allows me to use URIs such as: myapp/it/products/ myapp/en_US/products/ etc... I'd like, however, some more automation on this by using the "prefix" keywords, but it doesn't seem to work with prefixes. So, this: ------------------ prefix '/:lang/products'; get '/' => sub { return vars->{lang} . ' is the language'; }; ------------------ doesn't match. I also tried with regular expressions in routes, but didn't work either. Is there a way to make this work, without resorting tu URL rewriting? Thanks in advance, Michele. -- Michele Beltrame http://www.italpro.net/ - mb(a)italpro.net Skype: arthas77 - Twitter: _arthas

5 6

redirect to https
by Nick Knutov 19 Aug '11

19 Aug '11

In some control panels I need to redirect all users on https, something like before sub { return redirect 'https://'.request->host.request->request_uri if config->{environment} eq 'production' and not request->env->{HTTP_HTTPS}; [...] }; Is it a good way? My be it's already automated by some flag in config.yml? Additional, I found that password from session_cookie_key is not hidden when error occurs and show_errors: 1. it's a bug, I think. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130

1 0

Hidden setting forcing production environment.
by Michael Genereux 16 Aug '11

16 Aug '11

I don't know if anyone sees GitHub comments so I'll post here. In public/dispatch.cgi, there's a setting that forcibly sets the environment to production. The docs current provide information that has no effect. Here's what I posted: This setting really screwed me up as a new user of Dancer. (Loving it BTW.) The docs said to use Apache Environment variables and yet I couldn't get into development mode. Once I traced and commented this line out, Apache SetEnv worked great for me. I have development, staging, and production on a set of identical servers and they have same code but different environments controlled by Apache. I'm guessing no one else is doing development with Apache and is using the standalone app runner mostly. Should I submit a patch removing the Apache SetEnv docs? http://search.cpan.org/~sukria/Dancer-1.3071/lib/Dancer/Deployment.pod#Runn…

2 1

do something after sending response
by Nick Knutov 15 Aug '11

15 Aug '11

Hello all, is it possible to run some code after sending response to upstream [and closing socket] with Dancer? For example: I want to get request, send response and after closing socket to back-end do some job with big timeouts: write logs, send notifications via emails, etc. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130

11 18

Dancer::Exception
by damien krotkine 12 Aug '11

12 Aug '11

Hi, I'm in the midle of doing the second round coding for Dancer::Exception (it's in topic/exceptions2 on github). I have few design questions, and I'd like some feedback from the community. The plan is that with Dancer::Exception : - 1/ an exception has a value ( combination of power of 2 integers), and a message (string) - 2/ all exceptions raised by the Dancer core will be Dancer::Exception (instead of normal die / croak) - 3/ a user will be able to raise exceptions in the routes - 4/ a user will be able to create new exception types - 5/ when raised, exceptions are transmitted to the templating system when rendering a Dancer::Error - 6/ exceptions should properly stringify and numerify for backward compatibility and ease of use. - 7/ the user should have the opportunity to catch any Dancer exception and perform an appropriate action Currently, in the topic/exceptions2 branch, all items are implemented, except item 7. More precisely, it's possible to catch Dancer::Exception using standard eval {...}. But what if a user wants to catch an exception raised from a distant route, or from Dancer Core itself ? Real life example 1 : in some routes, the developer does some 'raise' of exceptions (internal or custom). The developer wants to run specific codes when these exception are raised. For now, he can wrap his route code with eval {} and use is_dancer_exception, as stated in Dancer::Exception. Real life example 2 : in some routes, the developper wants to catch core exceptions that could occur. Real life example 3 : if something wrong happens in the Dancer::Session::Yaml modules, it raises a E_SESSION exception. When this exception occurs, it'll render a Dancer::Error, stating that thet exception were a E_SESSION. However what would be cool is that you could catch the exceptions, see that it's of type SESSION, and in this case try a different Dancer::Session system. In this case the exception is a core one. example 3 is not related to routes, so it's a bit difficult to know where to put a try/catch scope. I have some ideas, but I'm not really convinced by them : - idea 1 : add a new hook, that would be called 'after_exception' - idea 2 : when an exception is raised, it's stored as Shared Data, and thus can be detected with a before_error hook - idea 3 : add a try_catch syntax when creating route, like : get '/foo' => sub { ... raise E_LOGIN, "bad credential" }, catch E_REQUEST | E_GENERIC => sub { ... } catch E_LOGIN => sub { ... } Currently, Dancer::Exception is not too bad : it's simple, efficient and fast. I don't want it to become a bloated system. But we need to provide a bit more feature for it to be really useful. Please share your thoughts :) dams.

2 2

Re: [Dancer-users] do something after sending response
by al 12 Aug '11

12 Aug '11

I thought about this the other day. I like the forking technique, but I suggest that if you install a signal handler in the main Dancer process upon startup, it should automatically reap any dead children and then you can fork to your hearts content without worrying about zombies. $SIG{CHLD} = sub { wait(); }

1 0