[Catalyst] Tweaking REST

[Adam Jacob]

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