Dear List,

I recently upgraded a project I'm working on to track some of the latest
changes in Catalyst::Action::REST, and noticed that in our application's
case the change to the 'serialize' config parameter altered the default
behavior of the application. The previous behavior had a config that
looked like:

serialize => {
default => 'application/json',
map => {
'application/json' => 'JSONP',
'text/x-php-serialization' => ['Data::Serializer',
'PHP::Serialization' ],

Would and still does, result in the application returning
'application/json' by default, because on line 182 of

$config = $controller->{'serialize'}

Overrides the default map!

However, if you use the new config style:

default => 'application/json',
map => {
'application/json' => 'JSONP',
'text/x-php-serialization' => ['Data::Serializer',
'PHP::Serialization' ],

The map entries are then appended to the default $config->map, and net
result is these additional mappings are never seen. This is because a
silly AJAX requests which never specified a content-type now use the
"default" behavior based on the browser's Accept-Encoding, which is
ALWAYS 'text/html'!

As a result, instead of returning a 'default' => 'application/json', it
quite rightly returns a default => 'text/html' which serializes based on

Based on the documentation, both behaviors are correct, but it seems to
me that if I specify a local mapping that it should override the default
map as it did in the old behavior. Was this change a bug or a design

- Dave Goehrig


Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 3 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedFeb 8, '10 at 2:52p
activeFeb 8, '10 at 8:18p

2 users in discussion

Tomas Doran: 2 posts Dave Goehrig: 1 post



site design / logo © 2022 Grokbase