| Subject: | C-A-REST fiddles with Catalyst->request_class |
| Date: | Mon, 29 Dec 2008 18:53:20 +0000 |
| To: | bugs-Catalyst-Action-REST [...] rt.cpan.org |
| From: | Matt S Trout <mst [...] shadowcat.co.uk> |
# This is wrong in several ways. First, there's no guarantee that
# Catalyst.pm has not been subclassed. Two, there's no guarantee that
# the user isn't already using their request subclass.
Catalyst->request_class('Catalyst::Request::REST')
unless Catalyst->request_class->isa('Catalyst::Request::REST');
It's horribly, evilly wrong.
Now, the correct approach would have been to tell the user to set
->request_class in MyApp.pm, but it's a bit late for that now.
My suggestion for the moment is: when you're constructed, you'll get a
'class' argument that'll be something like 'MyApp::Controller::Foo', from
that you can use Catalyst::Utils to get the app name, then you do
unless (MyApp->request_class->isa('Catalyst::Request::REST')) {
if (MyApp->request_class eq 'Catalyst::Request') {
MyApp->request_class('Catalyst::Request::REST');
} else {
die "You already have a custom request class, please make sure it's isa Catalyst::Request::REST";
}
}
or similar.
I'm aware this isn't perfect but custom request classes haven't got the
workout they need yet so I'm trying to get things cleaned up to not be
evil for 5.80, and then we can sit down and determine how to do it correctly
(probably by allowing ->request_class_roles or similar).
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/