catalyst-runtime
Catalyst - The Elegant MVC Web Application Framework
See the Catalyst::Manual distribution for comprehensive documentation and tutorials.
# Install Catalyst::Devel for helpers and other development tools # use the helper to create a new application catalyst.pl MyApp # add models, views, controllers script/myapp_create.pl model MyDatabase DBIC::Schema create=static dbi:SQLite:/path/to/db script/myapp_create.pl view MyTemplate TT script/myapp_create.pl controller Search # built in testserver -- use -r to restart automatically on changes # --help to see all available options script/myapp_server.pl # command line testing interface script/myapp_test.pl /yada ### in lib/MyApp.pm use Catalyst qw/-Debug/; # include plugins here as well ### In lib/MyApp/Controller/Root.pm (autocreated) sub foo : Chained('/') Args() { # called for /foo, /foo/1, /foo/1/2, etc. my ( $self, $c, @args ) = @_; # args are qw/1 2/ for /foo/1/2 $c->stash->{template} = 'foo.tt'; # set the template # lookup something from db -- stash vars are passed to TT $c->stash->{data} = $c->model('Database::Foo')->search( { country => $args[0] } ); if ( $c->req->params->{bar} ) { # access GET or POST parameters $c->forward( 'bar' ); # process another action # do something else after forward returns } } # The foo.tt TT template can use the stash data from the database [% WHILE (item = data.next) %] [% item.foo %] [% END %] # called for /bar/of/soap, /bar/of/soap/10, etc. sub bar : Chained('/') PathPart('/bar/of/soap') Args() { ... } # called after all actions are finished sub end : Action { my ( $self, $c ) = @_; if ( scalar @{ $c->error } ) { ... } # handle errors return if $c->res->body; # already have a response $c->forward( 'MyApp::View::TT' ); # render template }
See Catalyst::Manual::Intro for additional information.
Catalyst is a modern framework for making web applications without the pain usually associated with this process. This document is a reference to the main Catalyst application. If you are a new user, we suggest you start with Catalyst::Manual::Tutorial or Catalyst::Manual::Intro.
See Catalyst::Manual for more documentation.
Catalyst plugins can be loaded by naming them as arguments to the "use
Catalyst" statement. Omit the Catalyst::Plugin::
prefix from the
plugin name, i.e., Catalyst::Plugin::My::Module
becomesMy::Module
.
use Catalyst qw/My::Module/;
If your plugin starts with a name other than Catalyst::Plugin::
, you can
fully qualify the name by using a unary plus:
use Catalyst qw/ My::Module +Fully::Qualified::Plugin::Name /;
Special flags like -Debug
can also be specified as
arguments when Catalyst is loaded:
use Catalyst qw/-Debug My::Module/;
The position of plugins and flags in the chain is important, because they are loaded in the order in which they appear.
The following flags are supported:
Enables debug output. You can also force this setting from the system environment with CATALYST_DEBUG or _DEBUG. The environment settings override the application, with _DEBUG having the highest priority.
This sets the log level to 'debug' and enables full debug output on the error screen. If you only want the latter, see $c->debug.
Forces Catalyst to use a specific home directory, e.g.:
use Catalyst qw[-Home=/usr/mst];
This can also be done in the shell environment by setting either theCATALYST_HOME
environment variable or MYAPP_HOME
; where MYAPP
is replaced with the uppercased name of your application, any "::" in
the name will be replaced with underscores, e.g. MyApp::Web should use
MYAPP_WEB_HOME. If both variables are set, the MYAPP_HOME one will be used.
If none of these are set, Catalyst will attempt to automatically detect the
home directory. If you are working in a development environment, Catalyst
will try and find the directory containing either Makefile.PL, Build.PL,
dist.ini, or cpanfile. If the application has been installed into the system
(i.e. you have done make install
), then Catalyst will use the path to your
application module, without the .pm extension (e.g., /foo/MyApp if your
application was installed at /foo/MyApp.pm)
use Catalyst '-Log=warn,fatal,error';
Specifies a comma-delimited list of log levels.
Enables statistics collection and reporting.
use Catalyst qw/-Stats=1/;
You can also force this setting from the system environment with CATALYST_STATS or _STATS. The environment settings override the application, with _STATS having the highest priority.
Stats are also enabled if debugging is enabled.
Returns a Catalyst::Action object for the current action, which stringifies to the action name. See Catalyst::Action.
Returns the namespace of the current action, i.e., the URI prefix corresponding to the controller of the current action. For example:
# in Controller::Foo::Bar $c->namespace; # returns 'foo/bar';
Returns the current Catalyst::Request object, giving access to information about the current client request (including parameters, cookies, HTTP headers, etc.). See Catalyst::Request.
This is one way of calling another action (method) in the same or
a different controller. You can also use $self->my_method($c, @args)
in the same controller or $c->controller('MyController')->my_method($c, @args)
in a different controller.
The main difference is that 'forward' uses some of the Catalyst request
cycle overhead, including debugging, which may be useful to you. On the
other hand, there are some complications to using 'forward', restrictions
on values returned from 'forward', and it may not handle errors as you prefer.
Whether you use 'forward' or not is up to you; it is not considered superior to
the other ways to call a method.
'forward' calls another action, by its private name. If you give a
class name but no method, process()
is called. You may also optionally
pass arguments in an arrayref. The action will receive the arguments in@_
and $c->req->args
. Upon returning from the function,$c->req->args
will be restored to the previous values.
Any data return
ed from the action forwarded to, will be returned by the
call to forward.
my $foodata = $c->forward('/foo'); $c->forward('index'); $c->forward(qw/Model::DBIC::Foo do_stuff/); $c->forward('View::TT');
Note that forward implies
an eval { }
around the call (actuallyexecute does), thus rendering all
exceptions thrown by the called action non-fatal and pushing them onto
$c->error instead. If you want die
to propagate you need to do something
like:
$c->forward('foo'); die join "n", @{ $c->error } if @{ $c->error };
Or make sure to always return true values from your actions and write your code like this:
$c->forward('foo') || return;
Another note is that $c->forward
always returns a scalar because it
actually returns $c->state which operates in a scalar context.
Thus, something like:
return @array;
in an action that is forwarded to is going to return a scalar, i.e. how many items are in that array, which is probably not what you want. If you need to return an array then return a reference to it, or stash it like so:
$c->stash->{array} = @array;
and access it from the stash.
Keep in mind that the end
method used is that of the caller action. So a $c->detach
inside a forwarded action would run the end
method from the original action requested.
The same as forward, but doesn't return to the previous action when processing is finished.
When called with no arguments it escapes the processing chain entirely.
Almost the same as forward,
but does a full dispatch, instead of just calling the new $action
/$class->$method
. This means that begin
, auto
and the method
you go to are called, just like a new request.
In addition both $c->action
and $c->namespace
are localized.
This means, for example, that $c->action
methods such asname, class andreverse return information for the visited action
when they are invoked within the visited action. This is different from the
behavior of forward, which
continues to use the $c->action object from the caller action even when
invoked from the called action.
$c->stash
is kept unchanged.
In effect, visitallows you to "wrap" another action, just as it would have been called by dispatching from a URL, while the analogousgo allows you to transfer control to another action as if it had been reached directly from a URL.
The relationship between go
andvisit is the same as
the relationship betweenforward anddetach. Like $c->visit
,$c->go
will perform a full dispatch on the specified action or method,
with localized $c->action
and $c->namespace
. Like detach
,go
escapes the processing of the current request chain on completion, and
does not return to its caller.
@arguments are arguments to the final destination of $action. @captures are arguments to the intermediate steps, if any, on the way to the final sub of $action.
Returns the current Catalyst::Response object, see there for details.
Returns a hashref to the stash, which may be used to store data and pass it between components during a request. You can also set hash keys by passing arguments. The stash is automatically sent to the view. The stash is cleared at the end of a request; it cannot be used for persistent storage (for this you must use a session; seeCatalyst::Plugin::Session for a complete system integrated with Catalyst).
$c->stash->{foo} = $bar; $c->stash( { moose => 'majestic', qux => 0 } ); $c->stash( bar => 1, gorch => 2 ); # equivalent to passing a hashref # stash is automatically passed to the view for use in a template $c->forward( 'MyApp::View::TT' );
The stash hash is currently stored in the PSGI $env
and is managed byCatalyst::Middleware::Stash. Since it's part of the $env
items in
the stash can be accessed in sub applications mounted under your mainCatalyst application. For example if you delegate the response of an
action to another Catalyst application, that sub application will have
access to all the stash keys of the main one, and if can of course add
more keys of its own. However those new keys will not 'bubble' back up
to the main application.
For more information the best thing to do is to review the test case: t/middleware-stash.t in the distribution /t directory.
Returns an arrayref containing error messages. If Catalyst encounters an error while processing a request, it stores the error in $c->error. This method should only be used to store fatal error messages.
my @error = @{ $c->error };
Add a new error.
$c->error('Something bad happened');
Calling this will always return an arrayref (if there are no errors it will be an empty arrayref.
Contains the return value of the last executed action. Note that << $c->state >> operates in a scalar context which means that all values it returns are scalar.
Please note that if an action throws an exception, the value of state should no longer be considered the return if the last action. It is generally going to be 0, which indicates an error state. Examine $c->error for error details.
Clear errors. You probably don't want to clear the errors unless you are implementing a custom error screen.
This is equivalent to running
$c->error(0);
Returns true if you have errors
Returns the most recent error in the stack (the one most recently added...) or nothing if there are no errors. This does not modify the contents of the error stack.
shifts the most recently added error off the error stack and returns it. Returns nothing if there are no more errors.
pops the most recently added error off the error stack and returns it. Returns nothing if there are no more errors.
Gets a Catalyst::Controller instance by name.
$c->controller('Foo')->do_stuff;
If the name is omitted, will return the controller for the dispatched action.
If you want to search for controllers, pass in a regexp as the argument.
# find all controllers that start with Foo my @foo_controllers = $c->controller(qr{^Foo});
Gets a Catalyst::Model instance by name.
$c->model('Foo')->do_stuff;
Any extra arguments are directly passed to ACCEPT_CONTEXT, if the model defines ACCEPT_CONTEXT. If it does not, the args are discarded.
If the name is omitted, it will look for
a model object in $c->stash->{current_model_instance}, then
a model name in $c->stash->{current_model}, then
a config setting 'default_model', or
check if there is only one model, and return it if that's the case.
If you want to search for models, pass in a regexp as the argument.
# find all models that start with Foo my @foo_models = $c->model(qr{^Foo});
Gets a Catalyst::View instance by name.
$c->view('Foo')->do_stuff;
Any extra arguments are directly passed to ACCEPT_CONTEXT.
If the name is omitted, it will look for
a view object in $c->stash->{current_view_instance}, then
a view name in $c->stash->{current_view}, then
a config setting 'default_view', or
check if there is only one view, and return it if that's the case.
If you want to search for views, pass in a regexp as the argument.
# find all views that start with Foo my @foo_views = $c->view(qr{^Foo});
Returns the available names which can be passed to $c->controller
Returns the available names which can be passed to $c->model
Returns the available names which can be passed to $c->view
Gets a component object by name. This method is not recommended,
unless you want to get a specific component by full
class. $c->controller
, $c->model
, and $c->view
should be used instead.
If $name
is a regexp, a list of components matched against the full
component name will be returned.
If Catalyst can't find a component by name, it will fallback to regex matching by default. To disable this behaviour set disable_component_resolution_regex_fallback to a true value.
__PACKAGE__->config( disable_component_resolution_regex_fallback => 1 );
Returns or takes a hashref containing the application's configuration.
__PACKAGE__->config( { db => 'dsn:SQLite:foo.db' } );
You can also use a YAML
, XML
or Config::General config file
like myapp.conf
in your applications home directory. SeeCatalyst::Plugin::ConfigLoader.
The config method is present on all Catalyst components, and configuration
will be merged when an application is started. Configuration loaded withCatalyst::Plugin::ConfigLoader takes precedence over other configuration,
followed by configuration in your top level MyApp
class. These two
configurations are merged, and then configuration data whose hash key matches a
component name is merged with configuration for that component.
The configuration for a component is then passed to the new
method when a
component is constructed.
For example:
MyApp->config({ 'Model::Foo' => { bar => 'baz', overrides => 'me' } }); MyApp::Model::Foo->config({ quux => 'frob', overrides => 'this' });
will mean that MyApp::Model::Foo
receives the following data when
constructed:
MyApp::Model::Foo->new({ bar => 'baz', quux => 'frob', overrides => 'me', });
It's common practice to use a Moose attribute on the receiving component to access the config value.
package MyApp::Model::Foo; use Moose; # this attr will receive 'baz' at construction time has 'bar' => ( is => 'rw', isa => 'Str', );
You can then get the value 'baz' by calling $c->model('Foo')->bar (or $self->bar inside code in the model).
NOTE: you MUST NOT call $self->config
or __PACKAGE__->config
as a way of reading config within your code, as this will not give you the
correctly merged config back. You MUST take the config values supplied to
the constructor and use those instead.
Returns the logging object instance. Unless it is already set, Catalyst
sets this up with a Catalyst::Log object. To use your own log class,
set the logger with the __PACKAGE__->log
method prior to calling__PACKAGE__->setup
.
__PACKAGE__->log( MyLogger->new ); __PACKAGE__->setup;
And later:
$c->log->info( 'Now logging with my own logger!' );
Your log class should implement the methods described inCatalyst::Log.
Returned True if there's a valid encoding
Clears the encoding for the current context
Sets or gets the application encoding. Setting encoding takes either an Encoding object or a string that we try to resolve via Encode::find_encoding.
You would expect to get the encoding object back if you attempt to set it. If there is a failure you will get undef returned and an error message in the log.
Returns 1 if debug mode is enabled, 0 otherwise.
You can enable debug mode in several ways:
By calling myapp_server.pl with the -d flag
With the environment variables MYAPP_DEBUG, or CATALYST_DEBUG
The -Debug option in your MyApp.pm
By declaring sub debug { 1 }
in your MyApp.pm.
The first three also set the log level to 'debug'.
Calling $c->debug(1)
has no effect.
Returns the dispatcher instance. See Catalyst::Dispatcher.
Returns the engine instance. See Catalyst::Engine.
Merges @path
with $c->config->{home}
and returns aPath::Class::Dir object. Note you can usually use this object as
a filename, but sometimes you will have to explicitly stringify it
yourself by calling the ->stringify
method.
For example:
$c->path_to( 'db', 'sqlite.db' );
Initializes the dispatcher and engine, loads any plugins, and loads the
model, view, and controller components. You may also specify an array
of plugins to load here, if you choose to not load them in the use Catalyst
line.
MyApp->setup; MyApp->setup( qw/-Debug/ );
Note: You should not wrap this method with method modifiers
or bad things will happen - wrap the setup_finalize
method instead.
Note: You can create a custom setup stage that will execute when the application is starting. Use this to customize setup.
MyApp->setup(-Custom=value); sub setup_custom { my ($class, $value) = @_; }
Can be handy if you want to hook into the setup phase.
A hook to attach modifiers to. This method does not do anything except set thesetup_finished
accessor.
Applying method modifiers to the setup
method doesn't work, because of quirky things done for plugin setup.
Example:
after setup_finalize => sub { my $app = shift; ## do stuff here.. };
Constructs an absolute URI object based on the application root, the provided path, and the additional arguments and query parameters provided. When used as a string, provides a textual URI. If you need more flexibility than this (i.e. the option to provide relative URIs etc.) seeCatalyst::Plugin::SmartURI.
If no arguments are provided, the URI for the current action is returned.
To return the current action and also provide @args, use$c->uri_for( $c->action, @args )
.
If the first argument is a string, it is taken as a public URI path relative
to $c->namespace
(if it doesn't begin with a forward slash) or
relative to the application root (if it does). It is then merged with$c->request->base
; any @args
are appended as additional path
components; and any %query_values
are appended as ?foo=bar
parameters.
NOTE If you are using this 'stringy' first argument, we skip encoding and allow you to declare something like:
$c->uri_for('/foo/bar#baz')
Where 'baz' is a URI fragment. We consider this first argument string to be 'expert' mode where you are expected to create a valid URL and we for the most part just pass it through without a lot of internal effort to escape and encode.
If the first argument is a Catalyst::Action it represents an action which
will have its path resolved using $c->dispatcher->uri_for_action
. The
optional @captures
argument (an arrayref) allows passing the captured
variables that are needed to fill in the paths of Chained and Regex actions;
once the path is resolved, uri_for
continues as though a path was
provided, appending any arguments or parameters and creating an absolute
URI.
The captures for the current request can be found in$c->request->captures
, and actions can be resolved usingCatalyst::Controller->action_for($name)
. If you have a private action
path, use $c->uri_for_action
instead.
# Equivalent to $c->req->uri $c->uri_for($c->action, $c->req->captures, @{ $c->req->args }, $c->req->params); # For the Foo action in the Bar controller $c->uri_for($c->controller('Bar')->action_for('Foo')); # Path to a static resource $c->uri_for('/static/images/logo.png');
In general the scheme of the generated URI object will follow the incoming request however if your targeted action or action chain has the Scheme attribute it will use that instead.
Also, if the targeted Action or Action chain declares Args/CaptureArgs that have type constraints, we will require that your proposed URL verify on those declared constraints.
$path
A private path to the Catalyst action you want to create a URI for.
This is a shortcut for calling $c->dispatcher->get_action_by_path($path)
and passing the resulting $action
and the remaining arguments to $c->uri_for
.
You can also pass in a Catalyst::Action object, in which case it is passed to$c->uri_for
.
Note that although the path looks like a URI that dispatches to the wanted action, it is not a URI, but an internal path to that action.
For example, if the action looks like:
package MyApp::Controller::Users; sub lst : Path('the-list') {}
You can use:
$c->uri_for_action('/users/lst')
and it will create the URI /users/the-list.
@captures_and_args?
Optional array reference of Captures (i.e. CaptureArgs
or $c->req->captures
)
and arguments to the request. Usually used with Catalyst::DispatchType::Chainedto interpolate all the parameters in the URI.
@args?
Optional list of extra arguments - can be supplied in the@captures_and_args?
array ref, or here - whichever is easier for your
code.
Your action can have zero, a fixed or a variable number of args (e.g.Args(1)
for a fixed number or Args()
for a variable number)..
%query_values?
Optional array reference of query parameters to append. E.g.
{ foo => 'bar' }
will generate
/rest/of/your/uri?foo=bar
Returns the Catalyst welcome HTML page.
Contains a hash of options passed from the application script, including the original ARGV the script received, the processed values from that ARGV and any extra arguments to the script which were not processed.
This can be used to add custom options to your application's scripts and setup your application differently depending on the values of these options.
These methods are not meant to be used by end users.
Returns a hash of components.
Returns or sets the context class.
Returns a hashref containing coderefs and execution counts (needed for deep recursion detection).
Returns the number of actions on the current internal execution stack.
Dispatches a request to actions.
Returns or sets the dispatcher class.
Returns a list of 2-element array references (name, structure) pairs that will be dumped on the error page in debug mode.
Returns or sets the engine class.
Execute a coderef in given class and catch exceptions. Errors are available via $c->error.
Finalizes the request.
Finalizes body.
Finalizes cookies.
Finalizes error. If there is only one error in "error" and it is an object that
does as_psgi
or code
we rethrow the error and presume it caught by middleware
up the ladder. Otherwise we return the debugging error page (in debug mode) or we
return the default error page (production mode).
Finalizes headers.
Make sure your body is encoded properly IF you set an encoding. By default the encoding is UTF-8 but you can disable it by explicitly setting the encoding configuration value to undef.
We can only encode when the body is a scalar. Methods for encoding via the
streaming interfaces (such as write
and write_fh
on Catalyst::Responseare available).
See "ENCODING".
An alias for finalize_body.
Finalizes the input after reading is complete.
Finalizes uploads. Cleans up any temporary files.
Gets an action in a given namespace.
Gets all actions of a given name in a namespace and all parent namespaces.
Called to handle each HTTP request.
Creates a Catalyst context from an engine-specific request (Apache, CGI, etc.).
Prepares action. See Catalyst::Dispatcher.
Prepares message body.
Prepares a chunk of data before sending it to HTTP::Body.
See Catalyst::Engine.
Prepares body parameters.
Prepares connection.
Prepares cookies by ensuring that the attribute on the request object has been built.
Prepares request headers by ensuring that the attribute on the request object has been built.
Prepares parameters.
Prepares path and base.
Prepares query parameters.
Writes information about the request to the debug logs. This includes:
Request method, path, and remote IP address
Query keywords (see "query_keywords" in Catalyst::Request)
Request parameters
File uploads
Writes information about the response to the debug logs by calling$c->log_response_status_line
and $c->log_response_headers
.
Writes one line of information about the response to the debug logs. This includes:
Response status code
Content-Type header (if present)
Content-Length header (if present)
Hook method which can be wrapped by plugins to log the response headers. No-op in the default implementation.
Logs request parameters to debug logs
Logs file uploads included in the request to the debug logs. The parameter name, filename, file type, and file size are all included in the debug logs.
Hook method which can be wrapped by plugins to log the request headers. No-op in the default implementation.
Logs HTTP::Headers (either request or response) to the debug logs.
Prepares the input for reading.
Prepares the engine request.
Prepares uploads.
Prepares the output for writing.
Returns or sets the request class. Defaults to Catalyst::Request.
An arrayref of Moose::Roles which are applied to the request class. You can name the full namespace of the role, or a namespace suffix, which will then be tried against the following standard namespace prefixes.
$MyApp::TraitFor::Request::$trait_suffix Catalyst::TraitFor::Request::$trait_suffix
So for example if you set:
MyApp->request_class_traits(['Foo']);
We try each possible role in turn (and throw an error if none load)
Foo MyApp::TraitFor::Request::Foo Catalyst::TraitFor::Request::Foo
The namespace part 'TraitFor::Request' was chosen to assist in backwards compatibility with CatalystX::RoleApplicator which previously provided these features in a stand alone package.
This is the request class which has been composed with any request_class_traits.
Returns or sets the response class. Defaults to Catalyst::Response.
An arrayref of Moose::Roles which are applied to the response class. You can name the full namespace of the role, or a namespace suffix, which will then be tried against the following standard namespace prefixes.
$MyApp::TraitFor::Response::$trait_suffix Catalyst::TraitFor::Response::$trait_suffix
So for example if you set:
MyApp->response_class_traits(['Foo']);
We try each possible role in turn (and throw an error if none load)
Foo MyApp::TraitFor::Response::Foo Catalyst::TraitFor::Responset::Foo
The namespace part 'TraitFor::Response' was chosen to assist in backwards compatibility with CatalystX::RoleApplicator which previously provided these features in a stand alone package.
This is the request class which has been composed with any response_class_traits.
Reads a chunk of data from the request body. This method is designed to
be used in a while loop, reading $maxlength
bytes on every call.$maxlength
defaults to the size of the request if not specified.
You have to set MyApp->config(parse_on_demand => 1)
to use this
directly.
Warning: If you use read(), Catalyst will not process the body, so you will not be able to access POST parameters or file uploads via $c->request. You must handle all body parsing yourself.
Starts the engine.
Sets an action in a given namespace.
Sets up actions for a component.
This method is called internally to set up the application's components.
It finds modules by calling the locate_components method, expands them to package names with the expand_component_module method, and then installs each component into the application.
The setup_components
config option is passed to both of the above methods.
Installation of each component is performed by the setup_component method, below.
Called by setup_compoents to setup components that are injected.
Setup a given injected component.
Add a component that is injected at setup:
MyApp->inject_component( 'Model::Foo' => { from_component => 'Common::Foo' } );
Must be called before ->setup. Expects a component name for your current application and %args where
from_component
The target component being injected into your application
roles
An arrayref of Moose::Roles that are applied to your component.
Example
MyApp->inject_component( 'Model::Foo' => { from_component => 'Common::Model::Foo', roles => ['Role1', 'Role2'], });
Inject a list of components:
MyApp->inject_components( 'Model::FooOne' => { from_component => 'Common::Model::Foo', roles => ['Role1', 'Role2'], }, 'Model::FooTwo' => { from_component => 'Common::Model::Foo', roles => ['Role1', 'Role2'], });
This method is meant to provide a list of component modules that should be setup for the application. By default, it will use Module::Pluggable.
Specify a setup_components
config option to pass additional options directly
to Module::Pluggable. To add additional search paths, specify a key namedsearch_extra
as an array reference. Items in the array beginning with ::
will have the application class name prepended to them.
Components found by locate_components
will be passed to this method, which
is expected to return a list of component (package) names to be set up.
Returns a coderef that points to a setup_component instance. Used internally for when you want to delay setup until the first time the component is called.
Return the application level configuration (which is not yet merged with any local component configuration, via $component_class->config) for the named component or component object. Example:
MyApp->config( 'Model::Foo' => { a => 1, b => 2}, ); my $config = MyApp->config_for('MyApp::Model::Foo');
In this case $config is the hashref {a=>1, b=>2}
.
This is also handy for looking up configuration for a plugin, to make sure you follow existing Catalyst standards for where a plugin should put its configuration.
Sets up dispatcher.
Sets up engine.
Adds the following Plack middlewares to your application, since they are useful and commonly needed:
Plack::Middleware::LighttpdScriptNameFix (if you are using Lighttpd),Plack::Middleware::IIS6ScriptNameFix (always applied since this middleware is smart enough to conditionally apply itself).
We will also automatically add Plack::Middleware::ReverseProxy if we notice
that your HTTP $env variable REMOTE_ADDR
is '127.0.0.1'. This is usually
an indication that your server is running behind a proxy frontend. However in
2014 this is often not the case. We preserve this code for backwards compatibility
however I highly recommend that if you are running the server behind a front
end proxy that you clearly indicate so with the using_frontend_proxy
configuration
setting to true for your environment configurations that run behind a proxy. This
way if you change your front end proxy address someday your code would inexplicably
stop working as expected.
Additionally if we detect we are using Nginx, we add a bit of custom middleware to solve some problems with the way that server handles $ENV{PATH_INFO} and $ENV{SCRIPT_NAME}.
Please NOTE that if you do use using_frontend_proxy
the middleware is now
adding via registered_middleware
rather than this method.
If you are using Lighttpd or IIS6 you may wish to apply these middlewares. In general this is no longer a common case but we have this here for backward compatibility.
Returns a PSGI application code reference for the catalyst application$c
. This is the bare application created without the apply_default_middlewares
method called. We do however apply registered_middleware
since those are
integral to how Catalyst functions. Also, unlike starting your application
with a generated server script (via Catalyst::Devel and catalyst.pl
) we do
not attempt to return a valid PSGI application using any existing ${myapp}.psgi
scripts in your $HOME directory.
NOTE apply_default_middlewares
was originally created when the first PSGI
port was done for v5.90000. These are middlewares that are added to achieve
backward compatibility with older applications. If you start your application
using one of the supplied server scripts (generated with Catalyst::Devel and
the project skeleton script catalyst.pl
) we apply apply_default_middlewares
automatically. This was done so that pre and post PSGI port applications would
work the same way.
This is what you want to be using to retrieve the PSGI application code
reference of your Catalyst application for use in a custom .psgi
or in your
own created server modules.
Sets up the home directory.
Sets up the input/output encoding. See ENCODING
Hook to let you customize how encoding errors are handled. By default we just throw an exception and the default error page will pick it up. Receives a hashref of debug information. Example of call (from the Catalyst internals):
my $decoded_after_fail = $c->handle_unicode_encoding_exception({ param_value => $value, error_msg => $_, encoding_step => 'params', });
The calling code expects to receive a decoded string or an exception.
You can override this for custom handling of unicode errors. By default we just die. If you want a custom response here, one approach is to throw an HTTP style exception, instead of returning a decoded string or throwing a generic exception.
sub handle_unicode_encoding_exception { my ($c, $params) = @_; HTTP::Exception::BAD_REQUEST->throw(status_message=>$params->{error_msg}); }
Alternatively you can 'catch' the error, stash it and write handling code later in your application:
sub handle_unicode_encoding_exception { my ($c, $params) = @_; $c->stash(BAD_UNICODE_DATA=>$params); # return a dummy string. return 1; }
NOTE:</b> Please keep in mind that once an error like this occurs,
the request setup is still ongoing, which means the state of $c
and
related context parts like the request and response may not be setup
up correctly (since we haven't finished the setup yet). If you throw
an exception the setup is aborted.
Sets up log by instantiating a Catalyst::Log object and
passing it to This method also installs a Note that if the log has already been setup, by either a previous call to Sets up plugins. Sets up timing statistics class. Returns a sorted list of the plugins which have either been stated in the
import list. If passed a given plugin name, it will report a boolean value indicating
whether or not that plugin is loaded. A fully qualified name is required if
the plugin name does not begin with Returns a list of instantiated PSGI middleware objects which is the default
middleware that is active for this application (taking any configuration
options into account, excluding your custom added middleware via the The current default middleware list is: If the configuration setting If the configuration setting But NOTE that Plack::Middleware::ReverseProxyPath is not a dependency of theCatalyst distribution so if you want to use this option you should add it to
your project distribution file. These middlewares will be added at "setup_middleware" during the"setup" phase of application startup. Read only accessor that returns an array of all the middleware in the order
that they were added (which is the REVERSE of the order they will be applied). The values returned will be either instances of Plack::Middleware or of a
compatible interface, or a coderef, which is assumed to be inlined middleware Read configuration information stored in configuration key See under "CONFIGURATION" information regarding This method is automatically called during 'setup' of your application, so
you really don't need to invoke it. However you may do so if you find the idea
of loading middleware via configuration weird :). For example: When we read middleware definitions from configuration, we reverse the list
which sounds odd but is likely how you expect it to work if you have prior
experience with Plack::Builder or if you previously used the pluginCatalyst::Plugin::EnableMiddleware (which is now considered deprecated) So basically your middleware handles an incoming request from the first
registered middleware, down and handles the response from the last middleware
up. A read only copy of registered Data Handlers returned as a Hash, where each key
is a content type and each value is a subref that attempts to decode that content
type. Read configuration information stored in configuration key See under "CONFIGURATION" information regarding This method is automatically called during 'setup' of your application, so
you really don't need to invoke it. Default Data Handlers that come bundled with Catalyst. Currently there are
only two default data handlers, for 'application/json' and an alternative to
'application/x-www-form-urlencoded' which supposed nested form parameters viaCGI::Struct or via CGI::Struct::XS IF you've installed it. The 'application/json' data handler is used to parse incoming JSON into a Perl
data structure. It uses JSON::MaybeXS. This allows you to fail back toJSON::PP, which is a Pure Perl JSON decoder, and has the smallest dependency
impact. Because we don't wish to add more dependencies to Catalyst, if you wish to
use this new feature we recommend installing Cpanel::JSON::XS in order to get
the best performance. You should add either to your dependency list
(Makefile.PL, dist.ini, cpanfile, etc.) Returns an arrayref of the internal execution stack (actions that are
currently executing). Returns the current timing statistics object. By default Catalyst usesCatalyst::Stats, but can be set otherwise withstats_class. Even if -Stats is not enabled, the stats object is still
available. By enabling it with Returns or sets the stats (timing statistics) class. Catalyst::Stats is used by default. A arrayref of Moose::Roles that are applied to the stats_class before creating it. this is the stats_class composed with any 'stats_class_traits'. You can
name the full namespace of the role, or a namespace suffix, which will then
be tried against the following standard namespace prefixes. So for example if you set: We try each possible role in turn (and throw an error if none load) The namespace part 'TraitFor::Stats' was chosen to assist in backwards
compatibility with CatalystX::RoleApplicator which previously provided
these features in a stand alone package. Returns 1 when stats collection is enabled. Note that this is a static method, not an accessor and should be overridden
by declaring Writes $data to the output stream. When using this method directly, you
will need to manually set the Returns the Catalyst version number. Mostly useful for "powered by"
messages in template systems. There are a number of 'base' config variables which can be set: Most web server environments pass the requested path to the application using environment variables,
from which Catalyst has to reconstruct the request base (i.e. the top level path to / in the application,
exposed as There are two methods of doing this, both of which have advantages and disadvantages. Which method is used
is determined by the use_request_uri_for_path => 0 This is the default (and the) traditional method that Catalyst has used for determining the path information.
The path is generated from a combination of the However this method has the major disadvantage that it is impossible to correctly decode some elements
of the path, as RFC 3875 says: " use_request_uri_for_path => 1 This method uses the Given that this method of path resolution is provably more correct, it is recommended that you use
this unless you have a specific need to deploy your application in a non-standard environment, and you are
aware of the implications of not being able to handle encoded URI paths correctly. However it also means that in a number of cases when the app isn't installed directly at a path, but instead
is having paths rewritten into it (e.g. as a .cgi/fcgi in a public_html directory, with mod_rewrite in a
.htaccess file, or when SSI is used to rewrite pages into the app, or when sub-paths of the app are exposed
at other URIs than that which the app is 'normally' based at with This now defaults to 'UTF-8'. You my turn it off by setting this configuration
value to undef. Defaults to true. When there is an error in an action chain, the default behavior is to
abort the processing of the remaining actions to avoid running them
when the application is in an unexpected state. Before version 5.90070, the default used to be false. To keep the old
behaviour, you can explicitly set the value to false. E.g. If this setting is set to false, then the remaining actions are
performed and the error is caught at the end of the chain. In Catalyst::Request the methods Setting this configuration item to true will make Catalyst populate the
attributes underlying these methods with an instance of Hash::MultiValuewhich is used by Plack::Request and others to solve this very issue. You
may prefer this behavior to the default, if so enable this option (be warned
if you enable it in a legacy application we are not sure if it is completely
backwardly compatible). When creating body parameters from a POST, if we run into a multipart POST
that does not contain uploads, but instead contains inlined complex data
(very uncommon) we cannot reliably convert that into field => value pairs. So
instead we create an instance of Catalyst::Request::PartData. If this causes
issue for you, you can disable this by setting Generally we decode incoming POST params based on your declared encoding (the
default for this is to decode UTF-8). If this is causing you trouble and you
do not wish to turn all encoding support off (with the If true, then do not try to character decode any wide characters in your
request URL query or keywords. Most readings of the relevant specifications
suggest these should be UTF-* encoded, which is the default that Catalystwill 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
the UTF-8 decoding globally using this configuration. This setting takes precedence over Catalyst versions 5.90080 - 5.90106 would decode query parts of an incoming
request but would not raise an exception when the decoding failed due to
incorrect unicode. It now does, but if this change is giving you trouble
you may disable it by setting this configuration to true. By default we decode query and keywords in your request URL using UTF-8, which
is our reading of the relevant specifications. This setting allows one to
specify a fixed value for how to decode your query. You might need this if
you are doing a lot of custom encoding of your URLs and not using UTF-8. In older versions of Catalyst, when more than one action matched the same path
AND all those matching actions declared Args(0), we'd break the tie by choosing
the first action defined. We now normalized how Args(0) works so that it
follows the same rule as Args(N), which is to say when we need to break a tie
we choose the LAST action defined. If this breaks your code and you don't
have time to update to follow the new normalized approach, you may set this
value to true and it will globally revert to the original chaining behavior. An arrayref of Moose::Roles that get composed into your stats class. An arrayref of Moose::Roles that get composed into your request class. An arrayref of Moose::Roles that get composed into your response class. A Hashref of Catalyst::Component subclasses that are 'injected' into configuration.
For example: Generally Catalyst looks for components in your Model/View or Controller directories.
However for cases when you which to use an existing component and you don't need any
customization (where for when you can apply a role to customize it) you may inject those
components into your application. Please note any configuration should be done 'in the
normal way', with a key under configuration named after the component affix, as in the
above example. Using this type of injection allows you to construct significant amounts of your application
with only configuration!. This may or may not lead to increased code understanding. Please not you may also call the ->inject_components application method as well, although
you must do so BEFORE setup. Generally when you throw an exception inside an Action (or somewhere in
your stack, such as in a model that an Action is calling) that exception
is caught by Catalyst and unless you either catch it yourself (via eval
or something like Try::Tiny or by reviewing the "error" stack, it
will eventually reach "finalize_errors" and return either the debugging
error stack page, or the default error page. However, if your exception
can be caught by Plack::Middleware::HTTPExceptions, Catalyst will
instead rethrow it so that it can be handled by that middleware (which
is part of the default middleware). For example this would allow Catalyst uses internal actions like The request body is usually parsed at the beginning of a request,
but if you want to handle input yourself, you can enable on-demand
parsing with a config parameter. Many production servers operate using the common double-server approach,
with a lightweight frontend web server passing requests to a larger
backend server. An application running on the backend server must deal
with two problems: the remote user always appears to be Catalyst will automatically detect this situation when you are running
the frontend and backend servers on the same machine. The following
changes are made to the request. Additionally, you may be running your backend application on an insecure
connection (port 80) while your frontend proxy is running under SSL. If there
is a discrepancy in the ports, use the HTTP header In the case of passing in: All calls to Obviously, your web server must support these headers for this to work. In a more complex server farm environment where you may have your
frontend proxy server(s) on different machines, you will need to set a
configuration option to tell Catalyst to read the proxied data from the
headers. If you do not wish to use the proxy support at all, you may set: Note that if you supply your own .psgi file, calling You either need to apply Plack::Middleware::ReverseProxy yourself
in your psgi, for example: This will unconditionally add the ReverseProxy support, or you need to call See Catalyst::PSGI for more information. Catalyst has been tested under Apache 2's threading If you plan to operate in a threaded environment, remember that all other
modules you are using must also be thread-safe. Some modules, most notablyDBD::SQLite, are not thread-safe. The Catalyst::Request object uses HTTP::Body to populate 'classic' HTML
form parameters and URL search query fields. However it has become common
for various alternative content types to be PUT or POSTed to your controllers
and actions. People working on RESTful APIs, or using AJAX often use JSON,
XML and other content types when communicating with an application server. In
order to better support this use case, Catalyst defines a global configuration
option, By default Catalyst comes with a generic JSON data handler similar to the
example given above, which uses JSON::MaybeXS to provide either JSON::PP(a pure Perl, dependency free JSON parser) or Cpanel::JSON::XS if you have
it installed (if you want the faster XS parser, add it to you project Makefile.PL
or dist.ini, cpanfile, etc.) The This feature is considered an early access release and we reserve the right
to alter the interface in order to provide a performant and secure solution to
alternative request body content. Your reports welcomed! You can define middleware, defined as Plack::Middleware or a compatible
interface in configuration. Your middleware definitions are in the form of an
arrayref under the configuration key So the general form is: Where Alternatively, you may also define middleware by calling the "setup_middleware"package method: In the case where you do both (use 'setup_middleware' and configuration) the
package call to setup_middleware will be applied earlier (in other words its
middleware will wrap closer to the application). Keep this in mind since in
some cases the order of middleware is important. The two approaches are not exclusive. Middleware Object An already initialized object that conforms to the Plack::Middlewarespecification: coderef A coderef that is an inlined middleware: a scalar We assume the scalar refers to a namespace after normalizing it using the
following rules: (1) If the scalar is prefixed with a "+" (as in (2) If the scalar begins with "Plack::Middleware" or your application namespace
(the package name of your Catalyst application subclass), we also assume then
that it is a full namespace, and use it. (3) Lastly, we then assume that the scalar is a partial namespace, and attempt to
resolve it first by looking for it under your application namespace (for example
if you application is "MyApp::Web" and the scalar is "MyMiddleware", we'd look
under "MyApp::Web::Middleware::MyMiddleware") and if we don't find it there, we
will then look under the regular Plack::Middleware namespace (i.e. for the
previous we'd try "Plack::Middleware::MyMiddleware"). We look under your application
namespace first to let you 'override' common Plack::Middleware locally, should
you find that a good idea. Examples: a scalar followed by a hashref Just like the previous, except the following Please see PSGI for more on middleware. Starting in Catalyst version 5.90080 encoding is automatically enabled
and set to encode all body responses to UTF8 when possible and applicable.
Following is documentation on this process. If you are using an older
version of Catalyst you should review documentation for that version since
a lot has changed. By default encoding is now 'UTF-8'. You may turn it off by setting
the encoding configuration to undef. This is recommended for temporary backwards compatibility only. To turn it off for a single request use the clear_encodingmethod to turn off encoding for this request. This can be useful
when you are setting the body to be an arbitrary block of bytes,
especially if that block happens to be a block of UTF8 text. Encoding is automatically applied when the content-type is set to
a type that can be encoded. Currently we encode when the content type
matches the following regular expression: Encoding is set on the application, but it is copied to the context object
so that you can override it on a request basis. Be default we don't automatically encode 'application/json' since the most
common approaches to generating this type of response (Either via Catalyst::View::JSONor Catalyst::Action::REST) will do so already and we want to avoid double
encoding issues. If you are producing JSON response in an unconventional manner (such
as via a template or manual strings) you should perform the UTF8 encoding
manually as well such as to conform to the JSON specification. NOTE: We also examine the value of $c->response->content_encoding. If
you set this (like for example 'gzip', and manually gzipping the body)
we assume that you have done all the necessary encoding yourself, since
we cannot encode the gzipped contents. If you use a plugin likeCatalyst::Plugin::Compress you need to update to a modern version in order
to have this function correctly with the new UTF8 encoding code, or you
can use Plack::Middleware::Deflater or (probably best) do your compression on
a front end proxy. encoding Returns an instance of an handle_unicode_encoding_exception ($exception_context) Method called when decoding process for a request fails. An The default method throws exceptions in the case of invalid request parameters
(resulting in a 500 error), but ignores errors in upload filenames. The keys passed in the param_value The value which was not able to be decoded. error_msg The exception received from Encode. encoding_step What type of data was being decoded. Valid values are (currently) IRC: Mailing Lists: Web: Wiki: sri: Sebastian Riedel sri@cpan.org abw: Andy Wardley acme: Leon Brocard leon@astray.com abraxxa: Alexander Hartmaier abraxxa@cpan.org andrewalker: André Walker andre@cpan.org Andrew Bramble Andrew Ford A.Ford@ford-mason.co.uk Andrew Ruthven andyg: Andy Grundman andy@hybridized.org audreyt: Audrey Tang bricas: Brian Cassidy bricas@cpan.org Caelum: Rafael Kitover rkitover@io.com chansen: Christian Hansen Chase Venters chase.venters@gmail.com chicks: Christopher Hicks Chisel Wright pause@herlpacker.co.uk Danijel Milicevic me@danijel.de davewood: David Schmidt davewood@cpan.org David Kamholz dkamholz@cpan.org David Naughton naughton@umn.edu David E. Wheeler dhoss: Devin Austin dhoss@cpan.org dkubb: Dan Kubb dan.kubb-cpan@onautopilot.com Drew Taylor dwc: Daniel Westermann-Clark danieltwc@cpan.org esskar: Sascha Kiefer fireartist: Carl Franks cfranks@cpan.org frew: Arthur Axel "fREW" Schmidt frioux@gmail.com gabb: Danijel Milicevic Gary Ashton Jones Gavin Henry ghenry@perl.me.uk Geoff Richards groditi: Guillermo Roditi groditi@gmail.com hobbs: Andrew Rodland andrew@cleverdomain.org ilmari: Dagfinn Ilmari Mannsåker ilmari@ilmari.org jcamacho: Juan Camacho jester: Jesse Sheidlower jester@panix.com jhannah: Jay Hannah jay@jays.net Jody Belka Johan Lindstrom jon: Jon Schutz jjschutz@cpan.org Jonathan Rockway jrockway@cpan.org Kieren Diment kd@totaldatasolution.com konobi: Scott McWhirter konobi@cpan.org marcus: Marcus Ramberg mramberg@cpan.org miyagawa: Tatsuhiko Miyagawa miyagawa@bulknews.net mgrimes: Mark Grimes mgrimes@cpan.org mst: Matt S. Trout mst@shadowcatsystems.co.uk mugwump: Sam Vilain naughton: David Naughton ningu: David Kamholz dkamholz@cpan.org nothingmuch: Yuval Kogman nothingmuch@woobling.org numa: Dan Sully daniel@cpan.org obra: Jesse Vincent Octavian Rasnita omega: Andreas Marienborg Oleg Kostyuk cub.uanic@gmail.com phaylon: Robert Sedlacek phaylon@dunkelheit.at rafl: Florian Ragwitz rafl@debian.org random: Roland Lammel lammel@cpan.org revmischa: Mischa Spiegelmock revmischa@cpan.org Robert Sedlacek rs@474.at SpiceMan: Marcel Montes sky: Arthur Bergman szbalint: Balint Szilakszi szbalint@cpan.org t0m: Tomas Doran bobtfish@bobtfish.net Ulf Edvinsson vanstyn: Henry Van Styn vanstyn@cpan.org Viljo Marrandi vilts@yahoo.com Will Hawes info@whawes.co.uk willert: Sebastian Willert willert@cpan.org wreis: Wallace Reis wreis@cpan.org Yuval Kogman nothingmuch@woobling.org rainboxx: Matthias Dietrich perl@rainboxx.de dd070: Dhaval Dhanani dhaval070@gmail.com Upasana me@upasana.me John Napiorkowski (jnap) jjnapiork@cpan.org Copyright (c) 2005-2015, the above named PROJECT FOUNDER and CONTRIBUTORS. This library is free software. You can redistribute it and/or modify it under
the same terms as Perl itself.$c->setup_log
log()
. Pass in a comma-delimited list of levels to set the
log to.debug
method that returns a true value into the
catalyst subclass if the "debug" level is passed in the comma-delimited list,
or if the $CATALYST_DEBUG
environment variable is set to a true value.setup_log
or by a call such as __PACKAGE__->log( MyLogger->new )
,
that this method won't actually set up the log object.$c->setup_plugins
$c->setup_stats
$c->registered_plugins
Catalyst::Plugin::
.if ($c->registered_plugins('Some::Plugin')) {
...
}
default_middleware
psgi_middleware
configuration option). You can override this method if you wish to change
the default middleware (although do so at risk since some middleware is vital
to application function.) Catalyst::Middleware::Stash
Plack::Middleware::HTTPExceptions
Plack::Middleware::RemoveRedundantBody
Plack::Middleware::FixMissingBodyInRedirect
Plack::Middleware::ContentLength
Plack::Middleware::MethodOverride
Plack::Middleware::Head
using_frontend_proxy
is true we add: Plack::Middleware::ReverseProxy
using_frontend_proxy_path
is true we add: Plack::Middleware::ReverseProxyPath
registered_middlewares
setup_middleware (?@middleware)
psgi_middleware
or
from passed @args.psgi_middleware
and how
to use it to enable Plack::Middlewarepackage MyApp;
use Catalyst;
__PACKAGE__->setup_middleware('Head');
__PACKAGE__->setup;
registered_data_handlers
setup_data_handlers (?@data_handler)
data_handlers
or
from passed @args.data_handlers
.default_data_handlers
$c->stack
$c->stats
$c->stats->enabled(1)
, it can be used to
profile explicitly, although MyApp.pm still won't profile nor output anything
by itself.$c->stats_class
$app->stats_class_traits
$app->composed_stats_class
$MyApp::TraitFor::Stats::$trait_suffix
Catalyst::TraitFor::Stats::$trait_suffix
MyApp->stats_class_traits(['Foo']);
Foo
MyApp::TraitFor::Stats::Foo
Catalyst::TraitFor::Stats::Foo
$c->use_stats
sub use_stats { 1 }
in your MyApp.pm, not by calling $c->use_stats(1)
.$c->write( $data )
Content-Length
header to the length of
your output data, if known.version
CONFIGURATION
always_catch_http_exceptions
- As of version 5.90060 Catalyst
rethrows errors conforming to the interface described byPlack::Middleware::HTTPExceptions and lets the middleware deal with it.
Set true to get the deprecated behaviour and have Catalyst catch HTTP exceptions.default_model
- The default model picked if you say $c->model
. See "$c->model($name)".default_view
- The default view to be rendered or returned when $c->view
is called. See "$c->view($name)".disable_component_resolution_regex_fallback
- Turns
off the deprecated component resolution functionality so
that if any of the component methods (e.g. $c->controller('Foo')
)
are called then regex search will not be attempted on string values and
instead undef
will be returned.home
- The application home directory. In an uninstalled application,
this is the top level application directory. In an installed application,
this will be the directory containing MyApp.pm
.ignore_frontend_proxy
- See "PROXY SUPPORT"name
- The name of the application in debug messages and the debug and
welcome screensparse_on_demand
- The request body (for example file uploads) will not be parsed
until it is accessed. This allows you to (for example) check authentication (and reject
the upload) before actually receiving all the data. See "ON-DEMAND PARSER"root
- The root directory for templates. Usually this is just a
subdirectory of the home directory, but you can set it to change the
templates to a different directory.search_extra
- Array reference passed to Module::Pluggable to for additional
namespaces from which components will be loaded (and constructed and stored in$c->components
).show_internal_actions
- If true, causes internal actions such as _DISPATCH
to be shown in hit debug tables in the test server.use_request_uri_for_path
- Controls if the REQUEST_URI
or PATH_INFO
environment
variable should be used for determining the request path.$c->request->base
) and the request path below that base.$c->config(use_request_uri_for_path)
setting (which can either be true or false).PATH_INFO
and SCRIPT_NAME
environment variables.
The allows the application to behave correctly when mod_rewrite
is being used to redirect requests
into the application, as these variables are adjusted by mod_rewrite to take account for the redirect.Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot contain path-segment parameters.
" This means PATH_INFO is always decoded, and therefore Catalyst
can't distinguish / vs %2F in paths (in addition to other encoded values).REQUEST_URI
and SCRIPT_NAME
environment variables. As REQUEST_URI
is never
decoded, this means that applications using this mode can correctly handle URIs including the %2F character
(i.e. with AllowEncodedSlashes
set to On
in Apache).mod_rewrite
), the resolution of$c->request->base
will be incorrect.using_frontend_proxy
- See "PROXY SUPPORT".using_frontend_proxy_path
- Enabled Plack::Middleware::ReverseProxyPath on your application (if
installed, otherwise log an error). This is useful if your application is not running on the
'root' (or /) of your host server. NOTE if you use this feature you should add the required
middleware to your project dependency list since its not automatically a dependency of Catalyst.
This has been done since not all people need this feature and we wish to restrict the growth ofCatalyst dependencies.encoding
- See "ENCODING"abort_chain_on_error_fix
__PACKAGE__->config(abort_chain_on_error_fix => 0);
use_hash_multivalue_in_request
query_parameters
, body_parametes
and parameters
return a hashref where values might be scalar or an arrayref
depending on the incoming data. In many cases this can be undesirable as it
leads one to writing defensive code like the following: my ($val) = ref($c->req->parameters->{a}) ?
@{$c->req->parameters->{a}} :
$c->req->parameters->{a};
skip_complex_post_part_handling
skip_complex_post_part_handling
to true (default is false).skip_body_param_unicode_decoding
encoding
configuration
parameter) you may disable this step atomically by setting this configuration
parameter to true.do_not_decode_query
default_query_encoding
do_not_check_query_encoding
default_query_encoding
use_chained_args_0_special_case
psgi_middleware
- See "PSGI MIDDLEWARE".data_handlers
- See "DATA HANDLERS".stats_class_traits
request_class_traits
response_class_traits
inject_components
MyApp->config({
inject_components => {
'Controller::Err' => { from_component => 'Local::Controller::Errors' },
'Model::Zoo' => { from_component => 'Local::Model::Foo' },
'Model::Foo' => { from_component => 'Local::Model::Foo', roles => ['TestRole'] },
},
'Controller::Err' => { a => 100, b=>200, namespace=>'error' },
'Model::Zoo' => { a => 2 },
'Model::Foo' => { a => 100 },
});
EXCEPTIONS
use HTTP::Throwable::Factory 'http_throw';
sub throws_exception :Local {
my ($self, $c) = @_;
http_throw(SeeOther => { location =>
$c->uri_for($self->action_for('redirect')) });
}
INTERNAL ACTIONS
_DISPATCH
, _BEGIN
, _AUTO
,_ACTION
, and _END
. These are by default not shown in the private
action table, but you can make them visible with a config parameter.MyApp->config(show_internal_actions => 1);
ON-DEMAND PARSER
MyApp->config(parse_on_demand => 1);
PROXY SUPPORT
127.0.0.1
and
the server's hostname will appear to be localhost
regardless of the
virtual host that the user connected through.$c->req->address is set to the user's real IP address, as read from
the HTTP X-Forwarded-For header.
The host value for $c->req->base and $c->req->uri is set to the real
host, as read from the HTTP X-Forwarded-Host header.
X-Forwarded-Port
to
tell Catalyst what port the frontend listens on. This will allow all URIs to
be created properly.X-Forwarded-Port: 443
uri_for
will result in an https link, as is expected.MyApp->config(using_frontend_proxy => 1);
MyApp->config(ignore_frontend_proxy => 0);
Note about psgi files
MyApp->psgi_app(@_);
, then this will not happen automatically.builder {
enable "Plack::Middleware::ReverseProxy";
MyApp->psgi_app
};
$app = MyApp->apply_default_middlewares($app)
(to conditionally
apply the support depending upon your config).THREAD SAFETY
mpm_worker
,mpm_winnt
, and the standalone forking HTTP server on Windows. We
believe the Catalyst core to be thread-safe.DATA HANDLERS
data_handlers
, which lets you associate a content type with a coderef
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;
data_handlers
configuration is a hashref whose keys are HTTP Content-Types
(matched against the incoming request type using a regexp such as to be case
insensitive) and whose values are coderefs that receive a localized version of$_
which is a filehandle object pointing to received body.PSGI MIDDLEWARE
psgi_middleware
. Here's an example
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',
'+MyApp::Custom',
$stacktrace_middleware,
'Session' => {store => 'File'},
sub {
my $app = shift;
return sub {
my $env = shift;
$env->{myapp.customkey} = 'helloworld';
$app->($env);
},
},
],
);
__PACKAGE__->setup;
__PACKAGE__->config(psgi_middleware => @middleware_definitions);
@middleware
is one or more of the following, applied in the REVERSE of
the order listed (to make it function similarly to Plack::Builder:package MyApp::Web;
use Catalyst;
__PACKAGE__->setup_middleware( @middleware_definitions);
__PACKAGE__->setup;
my $stacktrace_middleware = Plack::Middleware::StackTrace->new;
__PACKAGE__->config(
'psgi_middleware', [
$stacktrace_middleware,
]);
__PACKAGE__->config(
'psgi_middleware', [
sub {
my $app = shift;
return sub {
my $env = shift;
if($env->{PATH_INFO} =~m/forced/) {
Plack::App::File
->new(file=>TestApp->path_to(qw/share static forced.txt/))
->call($env);
} else {
return $app->($env);
}
},
},
]);
+MyApp::Foo
) then the full string
is assumed to be 'as is', and we just install and use the middleware. package MyApp::Web;
__PACKAGE__->config(
'psgi_middleware', [
'Debug', ## MyAppWeb::Middleware::Debug->wrap or Plack::Middleware::Debug->wrap
'Plack::Middleware::Stacktrace', ## Plack::Middleware::Stacktrace->wrap
'+MyApp::Custom', ## MyApp::Custom->wrap
],
);
HashRef
is used as arguments
to initialize the middleware object. __PACKAGE__->config(
'psgi_middleware', [
'Session' => {store => 'File'},
]);
ENCODING
MyApp->config(encoding => undef);
$content_type =~ /^text|xml$|javascript$/
Methods
Encode
encoding print $c->encoding->name
$exception_context
hashref is provided to allow you to override the
behaviour of your application when given data with incorrect encodings.$exception_context
hash are:params
- for request parameters / arguments / captures
and uploads
- for request upload filenames.SUPPORT
Join #catalyst on irc.perl.org.
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
http://catalyst.perl.org
http://dev.catalyst.perl.org
SEE ALSO
Task::Catalyst - All you need to start with Catalyst
Catalyst::Manual - The Catalyst Manual
Catalyst::Component, Catalyst::Controller - Base classes for components
Catalyst::Engine - Core engine
Catalyst::Log - Log class.
Catalyst::Request - Request object
Catalyst::Response - Response object
Catalyst::Test - The test suite.
PROJECT FOUNDER
CONTRIBUTORS
COPYRIGHT
LICENSE
上一篇:vue-axios-github
下一篇:catalyst
还没有评论,说两句吧!
热门资源
seetafaceJNI
项目介绍 基于中科院seetaface2进行封装的JAVA...
spark-corenlp
This package wraps Stanford CoreNLP annotators ...
Keras-ResNeXt
Keras ResNeXt Implementation of ResNeXt models...
capsnet-with-caps...
CapsNet with capsule-wise convolution Project ...
inferno-boilerplate
This is a very basic boilerplate example for pe...
智能在线
400-630-6780
聆听.建议反馈
E-mail: support@tusaishared.com