With Dancer 1 we kind of just tried to make it work, while with Dancer2 we have a much (hopefully) clearer way to handle it in the way that works with Perl: * Decode to Perl representation when receiving input. * Encode to UTF-8 from Perl representation when producing output. Thus: * Serializers are expected to encode by themselves. * Template renderers also have the responsibility to encode to whatever encoding they want (usually UTF-8). A few emerging guides on this matter, outside the scope of Dancer: https://github.com/rgs/p5-intelligible-unicode/ http://dev.perltuts.com/tutorials/unicode-introduction https://github.com/Perl/perl5/compare/blead...rjbs/unicook I'm sure you know more on this topic than us though. :) On Thu, Dec 11, 2014 at 10:50 AM, Gabor Szabo <gabor@szabgab.com> wrote:

I used to have this code:

sub read_sites {

open my $fh, '<encoding(UTF-8)', mymaven->{root} . '/sites.yml'

or return {};

my $yaml = do { local $/ = undef; <$fh> };

from_yaml $yaml;

}

where sites.yml is this file: https://github.com/szabgab/perlmaven.com/blob/main/sites.yml

That worked well. Now it returns undef and does not evan complain about not being able to convert my yaml string to perl data structure.

=================

I see that in D1 from_yaml was this code:

YAML::Load($content);

In D2 it is now this code:

YAML::Load(decode('UTF-8', $content));

So I wonder, was I doing it all wrong earlier, but it worked because of the (mis)feature of Dancer? Should I refrain from using from_yaml at all for data I read in myself?

What was the recommended approach here for D1 and what is it for D2?

Gabor ps. Now that I saw this code, I am going to convert it to Path::Tiny, but I think the reason I have not used it earlier was that the 'path' function of that module and the 'path' function of Dancer would clash.

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users