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