[Catalyst-dev] RFC: Catalyst::View::Mason::Templated

Sebastian Willert willert at gmail.com
Tue Sep 18 15:16:48 GMT 2007


On Tue, 2007-09-18 at 08:43 -0500, Dave Rolsky wrote:
> On Tue, 18 Sep 2007, Sebastian Willert wrote:
> 
> > Mostly because it is the way Catalyst::View::Templated handles charsets
> > and I strove for maximum API compatibility with it. The charset is set
> > to utf-8 if is_utf8() returns true, though, but I didn't manage to force
> > Mason to produce anything but octet streams. I haven't looked too much
> > in this issue so if anyone can give me some advice concerning
> > HTML::Mason and charsets, please step up.
> 
> Mason is not doing any fiddling with your output, so if you output utf8, 
> that should work. To do that, you may need to add "use utf8" to all your 
> components, a job for Mason's pre-processing feature.

Mason works very well with utf8 components, apart from processing them
as octet streams as far as I can tell. This is no problem if you
explicitly set your content type, but you can't really tell if the
output is in utf8 or not and set the response header accordingly. I
think it is much saner to leave the content charset unspecified in such
a situation and let the browser figure out what to do (e.g. from HTML
header directives) than to force the response header to utf8 unless
explicitly stated.

I am not really happy with a solution that gives you no central
configuration point, or use a pre-processor for such a task (I guess
this is not really Masons fault here, IIRC the components are processed
as perl code and Mason can't really do anything about the internal
string representation), but I am even more unhappy with enforcing a
possibly dangerous default. I guess it's best to focus the discussion to
this point for now. Do you think assuming utf8 if no charset is given is
worthwhile?

Cheers,
  Sebastian




More information about the Catalyst-dev mailing list