X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FRequest%2FREST.pm;h=75caccd751156cc245a60bba6aae2b5319e7acf3;hb=d0822465cc09629df95ad9c522bce758f2badc8c;hp=ba606594836ab8441e61f858e7740a027b21716c;hpb=149182b33984f338616305abf6438822058085d2;p=catagits%2FCatalyst-Action-REST.git diff --git a/lib/Catalyst/Request/REST.pm b/lib/Catalyst/Request/REST.pm index ba60659..75caccd 100644 --- a/lib/Catalyst/Request/REST.pm +++ b/lib/Catalyst/Request/REST.pm @@ -7,6 +7,12 @@ use namespace::autoclean; extends 'Catalyst::Request'; with 'Catalyst::TraitFor::Request::REST'; +our $VERSION = '1.02'; +$VERSION = eval $VERSION; + +# Please don't take this as a recommended way to do things. +# The code below is grotty, badly factored and mostly here for back +# compat.. sub _insert_self_into { my ($class, $app_class ) = @_; # the fallback to $app_class is for the (rare and deprecated) case when @@ -17,22 +23,28 @@ sub _insert_self_into { my $req_class = $app->request_class; return if $req_class->isa($class); my $req_class_meta = Moose->init_meta( for_class => $req_class ); - return if $req_class_meta->does_role('Catalyst::TraitFor::Request::REST'); + my $role = $class->_related_role; + return if $req_class_meta->does_role($role); if ($req_class eq 'Catalyst::Request') { $app->request_class($class); } else { my $meta = Moose::Meta::Class->create_anon_class( superclasses => [$req_class], - roles => ['Catalyst::TraitFor::Request::REST'], + roles => [$role], cache => 1 ); - $meta->add_method(meta => sub { $meta }); + $meta->_add_meta_method('meta'); $app->request_class($meta->name); } } +sub _related_role { 'Catalyst::TraitFor::Request::REST' } + __PACKAGE__->meta->make_immutable; + +1; + __END__ =head1 NAME @@ -49,67 +61,20 @@ Catalyst::Request::REST - A REST-y subclass of Catalyst::Request =head1 DESCRIPTION -This is a subclass of C that adds a few methods to -the request object to faciliate writing REST-y code. Currently, these -methods are all related to the content types accepted by the client. - -Note that if you have a custom request class in your application, and it does -not inherit from C, your application will fail with an -error indicating a conflict the first time it tries to use -C's functionality. To fix this error, make sure your -custom request class inherits from C. - -=head1 METHODS - -=over - -=item data - -If the request went through the Deserializer action, this method will -return the deserialized data structure. - -=item accepted_content_types - -Returns an array reference of content types accepted by the -client. - -The list of types is created by looking at the following sources: - -=over 8 - -=item * Content-type header - -If this exists, this will always be the first type in the list. - -=item * content-type parameter - -If the request is a GET request and there is a "content-type" -parameter in the query string, this will come before any types in the -Accept header. - -=item * Accept header - -This will be parsed and the types found will be ordered by the -relative quality specified for each type. - -=back - -If a type appears in more than one of these places, it is ordered based on -where it is first found. - -=item preferred_content_type - -This returns the first content type found. It is shorthand for: - - $request->accepted_content_types->[0] +This is a subclass of C that applies the +L role to your request class. That trait +adds a few methods to the request object to facilitate writing REST-y code. -=item accepts($type) +This class is only here for backwards compatibility with applications already +subclassing this class. New code should use +L directly. -Given a content type, this returns true if the type is accepted. +L and L will arrange +for the request trait to be applied if needed. -Note that this does not do any wildcard expansion of types. +=head1 SEE ALSO -=back +L. =head1 AUTHORS