On Jan 30, 2007, at 7:13 AM, Christopher H. Laco wrote:
There are still some issues with using views, mainly that they both
fight of setting content-type...and since REST sets it already,
the view
never sets it, which is good, but also the charset=utf isn't set
either...
Just to solidify that statement...
__load_content_plugins sets the response content type to the strict
mapping itself sans the charset= part. Things like the TT view add the
charset=utf-8 if not encoding is set, but it already is, but that gets
trashed between the two, making using REST + UTF-8 producing views a
pita at first, and setting content_encoding makes no difference in
some
browsers.
Ultimately, doing this in the views template does the right thing:
[% CALL c.response.content_type('text/html; charset=utf-8') -%]
or
[% CALL c.response.content_type('text/plain; charset=utf-8') -%]
which imho is the better option, since each individual template
file/view may even use a different encoding...each view can tweak the
encoding, and not rely in the magic inner workings of REST when
using views.
Makes sense to me.
One thing to watch out for if you are combining the REST stuff with
other bits; the Accept header parsing. You're liable to need to map:
text/xml
application/xml
application/xhtml+xml
text/html
To something a browser can understand. Firefox ranks all four of
those content-types equally, but (if I remember correctly) we process
them in order.. so if you can do text/xml, and we can speak it, we'll
do it.
This may need to be a tweakable switch in C::A::REST... something like:
'accept_prefer' => [ 'text/html', 'application/xhtml+xml',
'application/xml', 'text/xml' ];
I'll add this to the todo list; if you don't get to it, I probably will.
Adam
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
