sub composed_response_class {
my $class = shift;
return $class->_composed_response_class if $class->_composed_response_class;
-
+
my @traits = (@{$class->response_class_traits||[]}, @{$class->config->{response_class_traits}||[]});
my $trait_ns = 'TraitFor::Response';
our $DETACH = Catalyst::Exception::Detach->new;
our $GO = Catalyst::Exception::Go->new;
-#I imagine that very few of these really
+#I imagine that very few of these really
#need to be class variables. if any.
#maybe we should just make them attributes with a default?
__PACKAGE__->mk_classdata($_)
}
my @middleware = map {
- ref $_ eq 'CODE' ?
- "Inline Coderef" :
- (ref($_) .' '. ($_->can('VERSION') ? $_->VERSION || '' : '')
+ ref $_ eq 'CODE' ?
+ "Inline Coderef" :
+ (ref($_) .' '. ($_->can('VERSION') ? $_->VERSION || '' : '')
|| '') } $class->registered_middlewares;
if (@middleware) {
# to do this early since encodable_response is false for this condition and we need
# to match the debug output for backcompat (there's a test for this...) -JNAP
if(
- $res->content_type_charset and $c->encoding and
+ $res->content_type_charset and $c->encoding and
(uc($c->encoding->mime_name) ne uc($res->content_type_charset))
) {
my $ct = lc($res->content_type_charset);
$c->res->body( $c->encoding->encode( $c->res->body, $c->_encode_check ) );
# Set the charset if necessary. This might be a bit bonkers since encodable response
- # is false when the set charset is not the same as the encoding mimetype (maybe
+ # is false when the set charset is not the same as the encoding mimetype (maybe
# confusing action at a distance here..
# Don't try to set the charset if one already exists or if headers are already finalized
$c->res->content_type($c->res->content_type . "; charset=" . $c->encoding->mime_name)
The namespace part 'TraitFor::Request' was chosen to assist in backwards
compatibility with L<CatalystX::RoleApplicator> which previously provided
these features in a stand alone package.
-
+
=head2 $app->composed_request_class
This is the request class which has been composed with any request_class_traits.
$class->components->{ $component } = $class->setup_component($component);
}
- return $instance;
+ return $instance;
}
=head2 $app->config_for( $component_name )
return;
}
-## This exists just to supply a prebuild psgi app for mod_perl and for the
+## This exists just to supply a prebuild psgi app for mod_perl and for the
## build in server support (back compat support for pre psgi port behavior).
## This is so that we don't build a new psgi app for each request when using
## the mod_perl handler or the built in servers (http and fcgi, etc).
}
## Look for a psgi file like 'myapp_web.psgi' (if the app is MyApp::Web) in the
-## home directory and load that and return it (just assume it is doing the
+## home directory and load that and return it (just assume it is doing the
## right thing :) ). If that does not exist, call $app->psgi_app, wrap that
## in default_middleware and return it ( this is for backward compatibility
## with pre psgi port behavior ).
my ($fh, $req) = @_;
require JSON::MaybeXS;
my $slurped;
- return eval {
+ return eval {
local $/;
$slurped = $fh->getline;
JSON::MaybeXS::decode_json($slurped); # decode_json does utf8 decoding for us
(very uncommon) we cannot reliably convert that into field => value pairs. So
instead we create an instance of L<Catalyst::Request::PartData>. If this causes
issue for you, you can disable this by setting C<skip_complex_post_part_handling>
-to true (default is false).
+to true (default is false).
=item *
suggest these should be UTF-* encoded, which is the default that L<Catalyst>
will use, however if you are creating a lot of URLs manually or have external
evil clients, this might cause you trouble. If you find the changes introduced
-in Catalyst version 5.90080+ break some of your query code, you may disable
+in Catalyst version 5.90080+ break some of your query code, you may disable
the UTF-8 decoding globally using this configuration.
This setting takes precedence over C<default_query_encoding>
that parses that content type into something Perl can readily access.
package MyApp::Web;
-
+
use Catalyst;
use JSON::MaybeXS;
-
+
__PACKAGE__->config(
data_handlers => {
'application/json' => sub { local $/; decode_json $_->getline },
},
## Any other configuration.
);
-
+
__PACKAGE__->setup;
By default L<Catalyst> comes with a generic JSON data handler similar to the
with details to follow:
package MyApp::Web;
-
+
use Catalyst;
use Plack::Middleware::StackTrace;
-
+
my $stacktrace_middleware = Plack::Middleware::StackTrace->new;
-
+
__PACKAGE__->config(
'psgi_middleware', [
'Debug',
},
],
);
-
+
__PACKAGE__->setup;
So the general form is:
some cases the order of middleware is important.
The two approaches are not exclusive.
-
+
=over 4
-
+
=item Middleware Object
-
+
An already initialized object that conforms to the L<Plack::Middleware>
specification:
-
+
my $stacktrace_middleware = Plack::Middleware::StackTrace->new;
-
+
__PACKAGE__->config(
'psgi_middleware', [
$stacktrace_middleware,
]);
-
-
+
+
=item coderef
-
+
A coderef that is an inlined middleware:
-
+
__PACKAGE__->config(
'psgi_middleware', [
sub {
},
},
]);
-
-
-
+
+
+
=item a scalar
-
+
We assume the scalar refers to a namespace after normalizing it using the
following rules:
'+MyApp::Custom', ## MyApp::Custom->wrap
],
);
-
+
=item a scalar followed by a hashref
-
+
Just like the previous, except the following C<HashRef> is used as arguments
to initialize the middleware object.
-
+
__PACKAGE__->config(
'psgi_middleware', [
'Session' => {store => 'File'},
projects / catagits/Catalyst-Runtime.git / blobdiff