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

Handling file uploads
by Stefan Oberwahrenbrock 25 Mar '11

25 Mar '11

Hello! I have some trouble handling file uploads with my first dancer app. Maybe someone can point me in the right direction: To get hold of an uploaded file sent via PUT, I have set up this route handler: put '/upload/:file' => sub { my $upload = upload( params->{file} ); debug "My Log 1: " . params->{file}; debug "My Log 2: " . ref($upload); }; To test the handler, I feed it with some data sent by "curl": curl --upload-file /srv/mydata.tar.gz http://localhost:3000/upload/ As far as I understand the documentation, $upload should hold a reference to an object of typ Dancer::Request::Upload now. Thus, methods like "filename", "basename", "tempname" etc. should be accessible. The logfile looks quite good - at the beginning: [3432] debug @0.003234> [hit #1] trying to match `/upload/mydata.tar.gz' against /^\/upload\/([^\/]+)$/ in /usr/local/share/perl/5.10.0/Dancer/Route.pm l. 73 [3432] debug @0.003493> [hit #1] My Log 1: mydata.tar.gz in lib/mywebapp.pm l. 26 But the next line indicates, that $upload is not what I expect it to be: [3432] debug @0.003550> [hit #1] My Log 2: in lib/mywebapp.pm l. 27 In addition to that, calling one of methods mentioned above (e. g. "$upload->filename()" ), produces a runtime error: Can't call method filename on an undefined value at... Probably I have not understood the upload() subroutine correctly - any hint is welcome! Thanks, Stefan -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

2 2

Invalid value for log config
by Gabor Szabo 22 Feb '11

22 Feb '11

After a misunderstanding in the environments/development.yml I changed the value of "log" to log: "console" which is incorrect (as this value belongs to logger) but I have not seen any complaints about it. Shouldn't DAncer check if the config params are valid? BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well. Gabor -- Gabor Szabo http://szabgab.com/

6 15

Multiple Dancer apps using Plack
by Harshal Shah 06 Feb '11

06 Feb '11

Hello I am trying to host multiple Dancer Apps using Plack. I've created a gist to demonstrate my code https://gist.github.com/800202 I am using *load_app 'App1', 'App2' *to load Dancer Apps in memory and consequently mounted the corresponding apps on /a1 and /a2 . But all request are getting redirected to App1 only. Am I doing this in a right manner ? Harshal Shah

2 1

Crash after upgrade to 1.3001
by Thomas Maier 05 Feb '11

05 Feb '11

Hi all, I have this simply setup that worked well under 1.2003 config.yml: template: template_toolkit layout: main views/header.tt: <DOCTYPE .... ... <body> views/index.tt <h1>test</h1> views/footer.tt </body> </html> views/layouts/main.tt [% INCLUDE header.tt %] [% content %] [% INCLUDE footer.tt %] lib/myapp.pm ... get '/' => sub { template 'index.tt' }; Request on http://localhost:3000/ gives now the follow error: [1914] core @0.004733> [hit #1]request to / crashed: '/path/to/dancer/myapp/views/' is not a regular file at /usr/local/share/perl/5.10.1/Dancer/Helpers.pm line 39 in /usr/local/share/perl/5.10.1/Dancer/Handler.pm l. 76 Any idea why ? Thanks Thomas

7 10

Re: [Dancer-users] Flash Message
by damien krotkine 30 Jan '11

30 Jan '11

Hi ! I've commented on github. Let's swithc to that for the following discussion indeed. Brian, you are more than welcome to participate :) dams On 29 January 2011 14:59, Flavio Poletti <polettix(a)gmail.com> wrote: > Hi all, > I don't know if this mailing list is actually the right place to > continue this discussion about this module implementation, let us know if > you're bored! > I implemented a generic approach and you can find it > here: https://github.com/polettix/Dancer-Plugin-FlashMessage/tree/alternatives > It is based on the configurability of three traits: > * how messages are registered ("queue" option) > * how additional parameters are handled ("arguments" option) > * how messages are flushed away ("dequeue" option). > There is a lot of new meat so I also added the full documentation with some > examples. This implementation is kinda back-compatible, with two outstanding > exceptions: > * persistence has been dropped, even though its functionality has been > absorbed by "dequeue" > * the 'flash' method now only *sets* messages, and it never deletes them. > IMHO, the case for deletion in the code is quite obscure, so I tried to move > this functionality inside the new "flash_flush" registered keyword. It is > anyway possible to revert to the old behaviour if it is considered better. > For any other aspects, the current default values replicate the previous > behaviour. > If it makes sense to you we can add a plethora of tests. > Thank you all for your patience, we'll probably better continue this > discussion on GitHub if you agree. > Flavio. > > > On Fri, Jan 28, 2011 at 7:05 PM, Flavio Poletti <polettix(a)gmail.com> wrote: >> >> >> On Fri, Jan 28, 2011 at 6:52 PM, damien krotkine <dkrotkine(a)gmail.com> >> wrote: >>> >>> On 28 January 2011 18:40, Flavio Poletti <polettix(a)gmail.com> wrote: >>> > Hi, >>> > >>> > the implementation is sound, even though I'd prefer to be able to >>> > set >>> > multiple messages per single channel. If I validate a form, for >>> > example, I'd >>> > like to flash a warning for each field I don't like, not just the last >>> > one. >>> >>> Hm, my brain being what it is on friday night, could you elaborate a >>> bit more ? can you give an example of such channels ? >>> >>> I'm thinking you could use an array of string as flash.warnings, >>> instead of a simple string, but I'm not sure I understand what you're >>> saying >> >> >> >> Sorry, you got the "channel" idea. I'd like to use flash like this: >> >> flash warning => 'you made error X'; >> >> and then, possibly later, say: >> >> flash warning => 'you made error Y'; >> >> In the current implementation, only the last gets to the template. I'm >> suggesting to always push the incoming $value into an array. Otherwise, with >> the current implementation that lets you delete stuff, I'd be forced to do >> it like this: >> >> my $array = flash('warning') || []; >> push @$array, 'you made error X'; >> flash warning => $array; >> >> which is a bit ugly... >> >> >>> >>> > On the other hand, deleting flash messages from the controller does >>> > seem to >>> > be a corner case, which I'd handle with an ad-hoc function or ignore >>> > completely. >>> > >>> > I'll try to propose something on GitHub that lets the end user decide >>> > the >>> > preferred semantics through a configuration; I would personally like to >>> > avoid having leftovers in the flash when my templates are not bug-free >>> > and I >>> > definitely don't like the idea of remembering to call flash->flush() >>> >>> I agree. After all, maybe it would make sense to have 3 behaviors : >>> behaviour 1 : delete all the keys as soon as one is used (to be >>> implemented ) >>> behaviour 2 : delete only the key which is used ( current implementation >>> ) >>> behaviour 3 : never delete the keys ( currently persistence = 1 ) >>> >>> And maybe behaviour 1 should be the default, I don't know. As long as >>> behaviour 2 is available, I'm happy (and brian too) >>> >>> maybe the behaviour could be chosen with the persistence config >>> keyword ? It could be renamed to flush_behaviour >>> >>> flush_behaviour = key_level >>> flush_behaviour = hash_level >>> flush_behaviour = never >>> >>> What do you think ? OK I'm terrible at finding good names, so any help >>> welcome :) >> >> >> I'd leave "_behaviour", add an 'always' (your previous implementation) and >> put something like: >> >> flush = 'key' >> flush = 'all' >> flush = 'always' >> flush = 'never' >> >> Anyway, as long as it's documented and it's reasonably connected to the >> behaviour everything is fine :-) >> >> >>> >>> > (even >>> > though it sounds so nice!) >>> >>> aha, yes, I like flash->flush :) Let's add it for fun, even if it's >>> not necessary :) >>> >>> >>> > >>> > Cheers, >>> > >>> > Flavio. >>> > >>> > On Fri, Jan 28, 2011 at 6:33 PM, damien krotkine <dkrotkine(a)gmail.com> >>> > wrote: >>> >> >>> >> I agree with Brian, for a slightly different reason : >>> >> >>> >> Let's imagine this: >>> >> >>> >> you have a Template1, that does this : <% flash.keys() %>, to be able >>> >> to know that they are errors. If that's the case, it doesn't display >>> >> the errors, but display a link, saying that they are erros. This link >>> >> does a new request against the server, serving Template2 >>> >> >>> >> Template2 does use flash.error, and effectively consumes the message. >>> >> >>> >> You don't want the flash hash structure to be emptied just after >>> >> having displayed Template1, you want the messages to survive until >>> >> Template2 (after all, you didn't consume them in Template1) >>> >> >>> >> If I understand correctly, In the original implementation, the simple >>> >> fact of getting the keys of the hash would delete all the messages, so >>> >> the next request, Template2 won't be able to retrieve <% flash.error >>> >> %> >>> >> >>> >> In my new implementation, it would work. >>> >> >>> >> Granted, this is a bit of a corner case, however, I don't see any >>> >> drawback. >>> >> >>> >> I could also add a flash->flush() method. >>> >> >>> >> >>> >> On 28 January 2011 18:09, Brian E. Lozier <brian(a)massassi.com> wrote: >>> >> > I can't think of any real world use case where you'd only want to >>> >> > show >>> >> > certain messages. That said, it still seems better to only clear >>> >> > the >>> >> > messages you use, not all of them. >>> >> > >>> >> > On Fri, Jan 28, 2011 at 9:02 AM, Flavio Poletti <polettix(a)gmail.com> >>> >> > wrote: >>> >> >> Hi, >>> >> >> >>> >> >> of course we can try to adapt to it (it seems a bit difficult >>> >> >> although >>> >> >> probably not impossible), but I fail to see the point. >>> >> >> >>> >> >> IMHO, if you get the chance to show the messages, you should show >>> >> >> them >>> >> >> all: >>> >> >> showing warnings in one page and errors in the following one would >>> >> >> puzzle >>> >> >> the end user, wouldn't it? >>> >> >> >>> >> >> Unless there is some use case that point in the opposite direction >>> >> >> I'd >>> >> >> stick >>> >> >> to the "wipe them all when you get the chance to show them" >>> >> >> semantics. >>> >> >> >>> >> >> Cheers, >>> >> >> >>> >> >> Flavio. >>> >> >> >>> >> >> On Fri, Jan 28, 2011 at 5:32 PM, Brian E. Lozier >>> >> >> <brian(a)massassi.com> >>> >> >> wrote: >>> >> >>> >>> >> >>> It looks like a pretty good solution. The only thing I can see >>> >> >>> would >>> >> >>> be that if you are in a template and check for flash.error but not >>> >> >>> flash.warning, it looks like it will clear both flash.error and >>> >> >>> flash.warning. It seems like it should only clear the one you're >>> >> >>> checking for. >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> On Fri, Jan 28, 2011 at 12:02 AM, Flavio Poletti >>> >> >>> <polettix(a)gmail.com> >>> >> >>> wrote: >>> >> >>> > Hi, >>> >> >>> > I thought a bit about it and I think that the current >>> >> >>> > implementation >>> >> >>> > is a >>> >> >>> > bit too limited (this seems also what brian thinks in the bug >>> >> >>> > report http://rt.cpan.org/Public/Bug/Display.html?id=65009 - at >>> >> >>> > least >>> >> >>> > from >>> >> >>> > what I understand). >>> >> >>> > The problem is that the flash message might have to be displayed >>> >> >>> > in >>> >> >>> > the >>> >> >>> > next >>> >> >>> > request, which happens when redirections kick in. In this case, >>> >> >>> > the >>> >> >>> > flash >>> >> >>> > message should be set, kept in the session and removed only when >>> >> >>> > it >>> >> >>> > is >>> >> >>> > actually displayed; this should happen automatically, i.e. >>> >> >>> > without >>> >> >>> > playing >>> >> >>> > with the $persistent variable - which is global - or with >>> >> >>> > further >>> >> >>> > overhead >>> >> >>> > on the controller side. >>> >> >>> > Following brian's feedback, I tried to re-code the plugin with >>> >> >>> > the >>> >> >>> > following >>> >> >>> > criteria: >>> >> >>> > * the "flash" method only adds messages (and handles many of >>> >> >>> > them >>> >> >>> > for >>> >> >>> > every >>> >> >>> > category - you might have more than one error in a page). I see >>> >> >>> > no >>> >> >>> > point >>> >> >>> > in >>> >> >>> > removing messages while inside the controller; >>> >> >>> > * the message removal logic is shifted in the template via an >>> >> >>> > anonymous >>> >> >>> > sub. >>> >> >>> > If the sub is called then the flash cache is cleared, otherwise >>> >> >>> > it >>> >> >>> > remains >>> >> >>> > there. This should guarantee that the messages are not removed >>> >> >>> > until >>> >> >>> > they >>> >> >>> > get the chance to be displayed. >>> >> >>> > This is the core of the recoding - not tested but should suffice >>> >> >>> > to >>> >> >>> > give >>> >> >>> > you >>> >> >>> > the idea: >>> >> >>> > register flash => sub { >>> >> >>> > my ($key, $value) = @_; >>> >> >>> > my $flash = session($session_hash_key); >>> >> >>> > if (! $flash) { # initialise the container for flash >>> >> >>> > messages >>> >> >>> > $flash = {}; >>> >> >>> > session($session_hash_key, $flash); >>> >> >>> > } >>> >> >>> > push @{$flash->{$key}}, $value; >>> >> >>> > return; >>> >> >>> > }; >>> >> >>> > before_template sub { >>> >> >>> > my $obj = shift; >>> >> >>> > my $flashes; >>> >> >>> > $obj->{$token_name} = sub { >>> >> >>> > if (! $flashes) { # first call, get messages and clear >>> >> >>> > $flashes = session($session_hash_key) || {}; >>> >> >>> > session($session_hash_key, {}); >>> >> >>> > } >>> >> >>> > return $flashes; >>> >> >>> > }; >>> >> >>> > return; >>> >> >>> > }; >>> >> >>> > >>> >> >>> > IMHO there is no need for an "exists", in the template you can >>> >> >>> > do >>> >> >>> > like >>> >> >>> > this: >>> >> >>> > <% IF flash.errors %>...<% END %> >>> >> >>> > The important thing to remember is that even checking for the >>> >> >>> > presence >>> >> >>> > of >>> >> >>> > something inside "flash" clears the messages, which is >>> >> >>> > consistent >>> >> >>> > with >>> >> >>> > the >>> >> >>> > semantics that "they get cleared as soon as they have a chance >>> >> >>> > to be >>> >> >>> > displayed". The $flashes variable guarantees that they survive >>> >> >>> > at >>> >> >>> > least >>> >> >>> > until the end of the request, i.e. you are able to call "flash" >>> >> >>> > multiple >>> >> >>> > times while handling a request and always get all messages. >>> >> >>> > If you think that this makes sense, I can propose a pull request >>> >> >>> > on >>> >> >>> > GitHub >>> >> >>> > or you can make the changes directly. >>> >> >>> > Cheers, >>> >> >>> > Flavio. >>> >> >>> > >>> >> >>> > >>> >> >>> > On Tue, Jan 11, 2011 at 5:48 PM, damien krotkine >>> >> >>> > <dkrotkine(a)gmail.com> >>> >> >>> > wrote: >>> >> >>> >> >>> >> >>> >> I've re-implemented it to be more Rails-like, as sukria said. >>> >> >>> >> >>> >> >>> >> https://github.com/dams/Dancer-Plugin-FlashMessage >>> >> >>> >> >>> >> >>> >> and on CPAN, pending mirrors refresh. >>> >> >>> >> >>> >> >>> >> The funny part of the story ? the effective code is only 30 >>> >> >>> >> lines >>> >> >>> >> long. Talking about Perl and Dancer expressiveness... >>> >> >>> >> >>> >> >>> >> dams. >>> >> >>> >> >>> >> >>> >> On 11 January 2011 14:40, Alexis Sukrieh <sukria(a)sukria.net> >>> >> >>> >> wrote: >>> >> >>> >> > Hi list! >>> >> >>> >> > >>> >> >>> >> > Le 11/01/2011 14:29, damien krotkine a écrit : >>> >> >>> >> >> >>> >> >>> >> >> Hi, >>> >> >>> >> >> >>> >> >>> >> >> following previous thread, I've done a first implementation >>> >> >>> >> >> of >>> >> >>> >> >> Dancer::Plugin::FlashMessage : >>> >> >>> >> >> >>> >> >>> >> >> https://github.com/dams/Dancer-Plugin-FlashMessage >>> >> >>> >> > >>> >> >>> >> > Great! Thanks a lot for your time dams, the myth is still >>> >> >>> >> > alived! >>> >> >>> >> > (Dancer's >>> >> >>> >> > community)++ >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> >> Some parts need to be improved, for instance : >>> >> >>> >> >> >>> >> >>> >> >> - it supports only one flash message >>> >> >>> >> >> - the keywords are not short enough. >>> >> >>> >> >> >>> >> >>> >> >> So I think I'll change the implementation so that the >>> >> >>> >> >> template >>> >> >>> >> >> token >>> >> >>> >> >> is >>> >> >>> >> >> simply called 'flash', and it'll be a hash, like in Rails. >>> >> >>> >> >> I'll >>> >> >>> >> >> also >>> >> >>> >> >> change the registered method so that it's just flash() >>> >> >>> >> >> instead >>> >> >>> >> >> of >>> >> >>> >> >> get_flash() >>> >> >>> >> > >>> >> >>> >> > I agree. I'd like to behave just like Rails' flash feature. >>> >> >>> >> > The >>> >> >>> >> > idea >>> >> >>> >> > is >>> >> >>> >> > pretty straight forward: >>> >> >>> >> > >>> >> >>> >> > "flash" is an accessor to a particular session hash table >>> >> >>> >> > whose >>> >> >>> >> > values >>> >> >>> >> > can >>> >> >>> >> > only be accessed once. Nothing more complicated than that. >>> >> >>> >> > >>> >> >>> >> > So to conclude, IMO, flash should be a wrapper like the >>> >> >>> >> > following: >>> >> >>> >> > >>> >> >>> >> > sub flash { >>> >> >>> >> > my ($key, $value) = @_; >>> >> >>> >> > my $flash = session('_flash'); >>> >> >>> >> > >>> >> >>> >> > # write >>> >> >>> >> > if (@_ == 2) { >>> >> >>> >> > $flash->{$key} = $value; >>> >> >>> >> > session('_flash' => $flash); >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > # read (+ delete) >>> >> >>> >> > else { >>> >> >>> >> > my $value = $flash->{$key}; >>> >> >>> >> > delete $flash->{$key} if defined $value; >>> >> >>> >> > session('_flash' => $flash); >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > return $value; >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > This is it, I think. This allows for the following code in a >>> >> >>> >> > Dancer >>> >> >>> >> > app: >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > get '/' => sub { >>> >> >>> >> > flash welcome => "This is a welcome message, only >>> >> >>> >> > shown >>> >> >>> >> > once"; >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > Then, as soon as the key 'welcome' is accesed via >>> >> >>> >> > flash('welcome'), >>> >> >>> >> > the >>> >> >>> >> > entry will be purged. >>> >> >>> >> > >>> >> >>> >> > This will be very helpful for authentication stuff in before >>> >> >>> >> > filters, >>> >> >>> >> > error >>> >> >>> >> > messages, notifications, .... >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > Kudos to dams! >>> >> >>> >> > >>> >> >>> >> > (BTW I haven't read the code yet) >>> >> >>> >> > >>> >> >>> >> > -- >>> >> >>> >> > Alexis Sukrieh >>> >> >>> >> > _______________________________________________ >>> >> >>> >> > Dancer-users mailing list >>> >> >>> >> > Dancer-users(a)perldancer.org >>> >> >>> >> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >>> >> > >>> >> >>> >> _______________________________________________ >>> >> >>> >> Dancer-users mailing list >>> >> >>> >> Dancer-users(a)perldancer.org >>> >> >>> >> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >>> > >>> >> >>> > >>> >> >>> > _______________________________________________ >>> >> >>> > Dancer-users mailing list >>> >> >>> > Dancer-users(a)perldancer.org >>> >> >>> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >>> > >>> >> >>> > >>> >> >>> _______________________________________________ >>> >> >>> Dancer-users mailing list >>> >> >>> Dancer-users(a)perldancer.org >>> >> >>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >> >>> >> >> >>> >> > _______________________________________________ >>> >> > Dancer-users mailing list >>> >> > Dancer-users(a)perldancer.org >>> >> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> > >>> > >>> > >> > >

2 1

Re: [Dancer-users] Matching a route including slashes (for directory listing)
by Joel Roth 30 Jan '11

30 Jan '11

On Sun, Jan 30, 2011 at 02:25:53PM +0200, sawyer x wrote: > On Sun, Jan 30, 2011 at 2:21 PM, Al Newkirk & Associates <we(a)ana.im> wrote: > > > On Sun, Jan 30, 2011 at 5:05 AM, sawyer x <xsawyerx(a)gmail.com> wrote: > > > >> On Sun, Jan 30, 2011 at 11:46 AM, Joel Roth <joelz(a)pobox.com> wrote: > >> > >> Hey Joel, > >> > >> If you know the level, and you want to be explicit, you can try the > >> default route syntax: '/media/*/*'. Thanks. Will test this out. > >> However, you will most likely prefer a regular expression (which you tried > >> earlier), and Dancer allows that very easily since Perl considers regexes as > >> first class: > >> get qr/.../ => sub { ... }; Of course. I shouldn't have confined my thinking to the cookbook/introduction. > >> We prefer to wrap qr() with something other than slashes, so we don't get > >> into a backslash fight: > >> get qr{ / media / (.*) }x => sub { ... }; \o/ > > >> Enjoy! > >> > >> > > I feel compelled to caution about how the use of regexs can open security > > holes in your application. Thanks for bringing this up. > > Another way to go would be to traverse the directory(s) and generate routes > > based on the findings in a before action. That was how I had originally done it, one level only, generating a page to represent the contents, as a cron job. A dynamic approach seemed easier, and suitable for this small site. Perhaps I'll go back to that, after trying out the regexen-- at least for my own satisfaction. Thanks to all! Joel > > That's a good point and a good idea! > > Thanks, Al! -- Joel Roth

1 0

Flash Message
by damien krotkine 30 Jan '11

30 Jan '11

Hi, following previous thread, I've done a first implementation of Dancer::Plugin::FlashMessage : https://github.com/dams/Dancer-Plugin-FlashMessage Some parts need to be improved, for instance : - it supports only one flash message - the keywords are not short enough. So I think I'll change the implementation so that the template token is simply called 'flash', and it'll be a hash, like in Rails. I'll also change the registered method so that it's just flash() instead of get_flash() Anything else you think should be changed/added ? Thanks. dams

6 18

Matching a route including slashes (for directory listing)
by Joel Roth 30 Jan '11

30 Jan '11

Hi all, I'm trying to create an Apache-style directory view with links to files and subdirectories and showing file length. I'm attempting to match a route like '/media/foo/bar' and generate a directory listing for /public/foo/bar. I was playing with this tonight: get '/media/*' => sub { my $path = splat; ... } This matches '/media/foo' but I was expecting it to match '/media/foo/bar'. It appears that * doesn't match slashes. '/media/([\w/]+)' doesn't seem to work, either. I'd welcome suggestions for either problem: 1. matching paths with several levels of hierarchy 2. listing a directory Kind regards, Joel -- Joel Roth

3 3

PerlDancer - The easiest way to write web applications with Perl
by Puneet Kishor 28 Jan '11

28 Jan '11

Congratulations on the new web site. Looks gorgeous. http://perldancer.org/ -- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ===========================================================================

2 1

Forward and accent
by Eric Guirbal 28 Jan '11

28 Jan '11

Hello, With dancer 1.3001, the new forward method doesn't work correctly with non ascii characters. $ dancer -a test In index.tt: <blockquote> Avant de choisir le prénom d'un garçon, pensez toujours à la femme qui aura à le murmurer plus tard. </blockquote> In test.pm add the route: get '/quote' => sub { forward '/'; } Run the application standalone et point your browser at http://localhost:3000/quote to see something awful. Regards, -- Eric

3 3