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

libdancer-perl in ubuntu ppa
by Иван Бессарабов 21 May '11

21 May '11

I prefer to install all libraries on production and even on development servers via debain package system. I've created the ppa https://launchpad.net/~bessarabov/+archive/star and placed there all perl modules that are needed by dancer. Now if you have clean ubuntu 10.04 install you only need to say: sudo apt-get install python-software-properties sudo add-apt-repository ppa:bessarabov/star sudo apt-get update sudo apt-get install libdancer-perl And after that you can run dancer apps =)

3 3

Dancer::Plugin::DBIC, plackup, and database connections
by Brian E. Lozier 20 May '11

20 May '11

I have written my app so far only in a "development" environment. I've just added some time zone handling and I'm worried I've programmed it such that different users can stomp on eachother's time zone. First, here is how it works currently: Detect user's time zone using javascript during registration (using https://bitbucket.org/pellepim/jstimezonedetect/wiki/Home ) and store it in the database. Please note that I don't care the timezone is exactly right, I just want to show reasonable dates/times by default. I might let them explicitly choose a time zone at some point in the future but that's not really what this question is about. When a user logs in I pull the tz info from the database and put it in their session. In a "before" handler I pull a database handle (dbh) from Dancer::Plugin::DBIC and set the session time zone like this: my $dbh = schema->storage->dbh(); $dbh->do("SET SESSION TIME ZONE ?", {}, $tz) or die("..some error..."); I'm currently running my application with plackup and then I have a nginx in front of that. The nginx serves all the "public" files (images, css) and then proxies to the actual web app for everything else. The problem is that I don't fully understand (or know where to find information on) the way Dancer::Plugin::DBIC and thus DBIC itself connects to the database. I'm wondering if the connections are persistent at all or if a new connection is created on each and every request. I've got a lot of experience with mod_perl and I've used Apache::DBI which pools connections and ensures that a handle isn't shared by multiple requests at the same time. I want to avoid a case where one user sets the time zone on the database session and then another user overwrites it. This should not happen if the connections are created on each request (but that can cause performance issues and I need to figure a way to have persistent connections) and it should also not matter if the db handle is dealt with similar to Apache::DBI. Thanks for any insight, Brian

1 0

Re: [Dancer-users] Custom Session Handler issues
by J. Bobby Lopez 19 May '11

19 May '11

---------- Forwarded message ---------- From: <igor.bujna(a)post.cz> Date: 2011/5/19 Subject: Re: [Dancer-users] Custom Session Handler issues To: "J. Bobby Lopez" <jbl(a)jbldata.com> Hello, I putted method like in CGI::Session to dancer. I send you my patch, to see simple how can be added session_expires in Dancer. My inspiration is in CGI::Session. I think it's better using this patch not used CGI::Session. This is my issue ttps://github.com/sukria/Dancer/issues/448 Bye Igor > ------------ Původní zpráva ------------ > Od: J. Bobby Lopez <jbl(a)jbldata.com> > Předmět: [Dancer-users] Custom Session Handler issues > Datum: 18.5.2011 17:47:03 > ---------------------------------------- > Hi all, > > I've been trying to track down the root of a problem I'm having with Dancer, > and a custom session handler that I am using. > > I've been told (several IRC discussions, and scouring the Dancer docs) that > unless I specifically enable sessions within dancer (either simple or YAML), > that no session handling code gets initialized by default in Dancer. > > However I'm finding that something is preventing my CGI::Session files from > being written to disk, as they are in my other non-dancer applications using > code similar to the following: > > http://pastebin.jbldata.com/m2571aaf0 > > This isn't the precise code I'm trying to use in my application, but has > been simplified in order to provide the same results without a lot of noise. > > The code defines that the CGI::Session driver writes session files to > '/tmp', however no session files are written there. Running this app, you > can clearly see that the custom session handler is working when you run the > application from the command line (e.g, 'perl dancer-sessiontest.pl'), and > visit the application in a browser using the '/' or '/dump_session' routes. > > If these files are not written to the directory I've specified, then likely > they are being stored in memory, but how and why is it doing that if Dancer > does not do any session handling by default? As you can see, I'm using a > very skeletal, single file Dancer application, which does not attempt to > load any of Dancer's session handling modules. > > Can anyone explain what is happening here, and how to get my session files > handled correctly? > > Thanks very much for any assistance, > -Bobby > > >

1 0

using LWP::Simple with Dancer
by Mr. Puneet Kishor 15 May '11

15 May '11

There is perhaps another way, probably very simple, but I am drawing a blank. In my web app, I want to download the content at a few different URIs, strip them off the tags, and store the text for further processing. A simple command line script uses LWP::Simple to download the content, then HTTP::Strip removes the tags. This script works from the command line, But, within Dancer, I get a 'get is redefined' error. How can I implement such functionality within Dancer? Puneet.

3 3

template with { layout => undef } doesn't seem to work
by Brian E. Lozier 12 May '11

12 May '11

In the docs it says: For example, to disable the layout for a specific request: get '/' => sub { template 'index.tt', {}, { layout => undef }; }; But when I do this: my $message = template('email/registration_confirmation.tt', { hash => $hash, }, { layout => undef, }, ); The layout is still applied. I am using Dancer-1.3040. Can anyone spot what I'm doing wrong? Thanks, Brian

2 4

_method parameter
by Nicolas Steenlant 11 May '11

11 May '11

hello everybody, are there any plans to support a _method query parameter? this seems to be emerging as the convention to force put and delete, especially now that html5 forms will only support get and post. it's easily handled with a before filter, but stil thanks, Nicolas

3 2

Dancer + Plack/Starman - location of .psgi matters?
by Richard Huxton 09 May '11

09 May '11

It seems to matter whether my .psgi is in MyApp/bin or MyApp/other This works: starman -E development -a bin/app.development.psgi ... This doesn't (complains about config not being loaded): starman -E development -a res/app.development.psgi ... Makes no difference if I give a full path or not. I get the same error with "plackup" rather than "starman" too. Current versions of Dancer/Starmam. I'm guessing it's something to do with Dancer figuring out paths, but can't quite figure out what. TIA --- app.development.psgi file --- use Dancer; use Plack; load_app 'MyApp'; use Dancer::Config 'setting'; setting apphandler => 'PSGI'; Dancer::Config->load; my $app1 = sub { my $env = shift; my $request = Dancer::Request->new( $env ); Dancer->dance( $request ); }; -- Richard Huxton Archonet Ltd

3 3

Collision of multiple Dancer apps using Plack::Handler::Apache2
by Matthew Robinson 09 May '11

09 May '11

Hi, I have just discovered a problem with a couple of Dancer apps that we have deployed onto the same Apache using Plack::Handler::Apache2. The apps are configured in separate virtual hosts but the routes and other configuration is getting confused between the two apps. I checked the mailing list archive and found this message from September of last year which seems to be the problem we have encountered. Unfortunately, there doesn¹t appear to have been any response to the message: http://lists.perldancer.org/pipermail/dancer-users/2010-September/000344.htm l Is this something that has been fixed? Or has a workaround? In the meantime we have had to switch one of our apps back to using CGI but we can¹t take this performance hit for too long. Other than this issue we are loving Dancer :) Thanks, Matt

2 1

Exploring Best Practices for Route Definition
by J. Bobby Lopez 05 May '11

05 May '11

Hello Dancers, I recently asked a question on #dancer regarding how to deal with trailing slashes on routes. There was a brief discussion which resulted, and I've copied the the discussion below in order to get some more input on the matter. (with permission from gnusosa) please see the discussion below: ----------irc.perl.org------#dancer------------------------ 14:54 < jbl> curious how others treat the difference between 'route' and 'route/' in dancer. I'm often using '/some/route', but then if a user tries to access the app with http://site.com/some/route/' (with the trailing slash) it gives a 404 by default. What's the usual cure for this problem? 14:55 < gnusosa> jbl: Good Question. 14:59 < gnusosa> jbl: This is going to happen since the slash "/" is the one that difference the route from the route/ 15:02 < jbl> right 15:03 < jbl> I'm just wondering if I should add a wildcard or redirect to catch trailing slashes, or if there is a setting somewhere that checks if there are no other characters after the slash, to just treat it as base route 15:03 < jbl> not sure I'm being clear on that :\ 15:04 < jbl> I think I saw the use of regexs for routes somewhere, that might be a good option 15:06 < jbl> to do something like: get '/myroute[/]*$' 15:07 < jbl> or maybe even just strip the trailing slashes using a 'before' statement 15:07 < gnusosa> jbl: Probably. 15:07 < jbl> curse of tmtowtdi 15:08 < gnusosa> jbl: But all of these seems like too much hassle. 15:08 < gnusosa> jbl: What is the problem with sending some people to 404 :P 15:10 < jbl> I guess that if the URL doesn't have an extension "/route.cgi" then some people (maybe just me) may feel that URL is incomplete/incorrect/odd somehow. I guess they could go to a 404 if they type in the URL manually 15:11 < jbl> no real harm in that as long as the real URL works 15:11 < jbl> just feels off 15:11 < gnusosa> jbl: umm I understand now. 15:12 < jbl> and I remember at some point (back in the day) it was good practice to end URLs with a slash, if it wasn't going to a 'file' 15:16 < gnusosa> jbl: You should email the mailing list dancer-users(a)perldancer.org with this issue. Best practices in the routes are a big deal. ------------------------------------

4 3

IRC logs
by Иван Бессарабов 05 May '11

05 May '11

A lot of dancer discussion is made on IRC channel #dancer on irc.perl.org. I want to know if the discussions there are saved somewhere and is it possible to read them latter without using irc clients.

3 3