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