On 8 Feb 2010, at 14:52, Dave Goehrig wrote:
However, if you use the new config style:
__PACKAGE__->config(
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.
However, if you use the new config style:
__PACKAGE__->config(
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.
They're merged, in the normal way that config is merged.
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
Catalyst::Action::YAML::HTML
Erm, this isn't anything to do with the 'default'.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
Catalyst::Action::YAML::HTML
The default is only used when you have NO Accept OR Content-Type
headers at all..
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.
Yes, if you map text/html to JSONP, then it'll work (overriding theto
me that if I specify a local mapping that it should override the
default
map as it did in the old behavior.
default) :)
Was this change a bug or a design
decision?
I'm no longer sure, as I'm not sure what problem you're reporting /decision?
what the actual behavior change is.
I wrote a test to try to prove your issue, but it works like I expect
it to:
http://git.shadowcat.co.uk/gitweb/gitweb.cgi?pÊtagits/Catalyst-Action-REST.git;a=commitdiff;h–0e29eed9ccd049c3c0dcd78a65308242a64ae0
Can you write me a similar test which passes on the version you were
running, but fails on a later version (and tell me which versions
these are) - so that I can work out what the _actual_ behavior change
which caused your issue is?
Cheers
t0m
