-Debug¶

Enables debug output. You can also force this setting from the system environment with CATALYST_DEBUG or <MYAPP>_DEBUG. The environment settings override the application, with <MYAPP>_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".

-Home¶

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 the "CATALYST_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)

-Log¶

    use Catalyst '-Log=warn,fatal,error';

Specifies a comma-delimited list of log levels.

-Stats¶

Enables statistics collection and reporting.

   use Catalyst qw/-Stats=1/;

You can also force this setting from the system environment with CATALYST_STATS or <MYAPP>_STATS. The environment settings override the application, with <MYAPP>_STATS having the highest priority.

Stats are also enabled if debugging is enabled.

INFORMATION ABOUT THE CURRENT REQUEST¶

$c->action¶

Returns a Catalyst::Action object for the current action, which stringifies to the action name. See Catalyst::Action.

$c->namespace¶

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';

$c->request¶

$c->req¶

Returns the current Catalyst::Request object, giving access to information about the current client request (including parameters, cookies, HTTP headers, etc.). See Catalyst::Request.

There is a predicate method "has_request" that returns true if the request object has been created. This is something you might need to check if you are writing plugins that run before a request is finalized.

REQUEST FLOW HANDLING¶

$c->forward( $action [, \@arguments ] )¶

$c->forward( $class, $method, [, \@arguments ] )¶

$c->forward( $component_instance, $method, [, \@arguments ] )¶

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 (actually execute 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.

If you call "forward" with the name of a component class or instance, rather than an action name or instance, we invoke the "process" action on that class or instance, or whatever action you specify via the second argument $method.

$c->detach( $action [, \@arguments ] )¶

$c->detach( $class, $method, [, \@arguments ] )¶

$c->detach()¶

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.

$c->visit( $action [, \@arguments ] )¶

$c->visit( $action [, \@captures, \@arguments ] )¶

$c->visit( $class, $method, [, \@arguments ] )¶

$c->visit( $class, $method, [, \@captures, \@arguments ] )¶

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 as name, class and reverse 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, visit allows you to "wrap" another action, just as it would have been called by dispatching from a URL, while the analogous go allows you to transfer control to another action as if it had been reached directly from a URL.

$c->go( $action [, \@arguments ] )¶

$c->go( $action [, \@captures, \@arguments ] )¶

$c->go( $class, $method, [, \@arguments ] )¶

$c->go( $class, $method, [, \@captures, \@arguments ] )¶

The relationship between "go" and visit is the same as the relationship between forward and detach. 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.

$c->response¶

$c->res¶

Returns the current Catalyst::Response object, see there for details.

There is a predicate method "has_response" that returns true if the request object has been created. This is something you might need to check if you are writing plugins that run before a request is finalized.

$c->stash¶

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; see Catalyst::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 by Catalyst::Middleware::Stash. Since it's part of the $env items in the stash can be accessed in sub applications mounted under your main Catalyst 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.

$c->error¶

$c->error($error, ...)¶

$c->error($arrayref)¶

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.

$c->state¶

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.

$c->clear_errors¶

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);

$c->has_errors¶

Returns true if you have errors

$c->last_error¶

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.

shift_errors¶

shifts the most recently added error off the error stack and returns it. Returns nothing if there are no more errors.

pop_errors¶

pops the most recently added error off the error stack and returns it. Returns nothing if there are no more errors.

COMPONENT ACCESSORS¶

$c->controller($name)¶

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});

$c->model($name)¶

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});

$c->view($name)¶

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});

$c->controllers¶

Returns the available names which can be passed to $c->controller

$c->models¶

Returns the available names which can be passed to $c->model

$c->views¶

Returns the available names which can be passed to $c->view

$c->comp($name)¶

$c->component($name)¶

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 );

CLASS DATA AND HELPER CLASSES¶

$c->config¶

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. See Catalyst::Plugin::ConfigLoader.

Cascading configuration

The config method is present on all Catalyst components, and configuration will be merged when an application is started. Configuration loaded with Catalyst::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.

$c->log¶

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 in Catalyst::Log.

has_encoding¶

Returned True if there's a valid encoding

clear_encoding¶

Clears the encoding for the current context

encoding¶

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.

$c->debug¶

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.

$c->dispatcher¶

Returns the dispatcher instance. See Catalyst::Dispatcher.

$c->engine¶

Returns the engine instance. See Catalyst::Engine.

UTILITY METHODS¶

$c->path_to(@path)¶

Merges @path with "$c->config->{home}" and returns a Path::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' );

MyApp->setup¶

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.

$app->setup_finalize¶

A hook to attach modifiers to. This method does not do anything except set the "setup_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..
    };

$c->uri_for( $path?, @args?, \%query_values?, \$fragment? )¶

$c->uri_for( $action, \@captures?, @args?, \%query_values?, \$fragment? )¶

$c->uri_for( $action, [@captures, @args], \%query_values?, \$fragment? )¶

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.) see Catalyst::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 using "Catalyst::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.

$c->uri_for_action( $path, \@captures_and_args?, @args?, \%query_values? )¶

$c->uri_for_action( $action, \@captures_and_args?, @args?, \%query_values? )¶

$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::Chained to 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
    

$c->welcome_message¶

Returns the Catalyst welcome HTML page.

run_options¶

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.

$c->components¶

Returns a hash of components.

$c->context_class¶

Returns or sets the context class.

$c->counter¶

Returns a hashref containing coderefs and execution counts (needed for deep recursion detection).

$c->depth¶

Returns the number of actions on the current internal execution stack.

$c->dispatch¶

Dispatches a request to actions.

$c->dispatcher_class¶

Returns or sets the dispatcher class.

$c->dump_these¶

Returns a list of 2-element array references (name, structure) pairs that will be dumped on the error page in debug mode.

$c->engine_class¶

Returns or sets the engine class.

$c->execute( $class, $coderef )¶

Execute a coderef in given class and catch exceptions. Errors are available via $c->error.

$c->finalize¶

Finalizes the request.

$c->log_stats¶

Logs statistics.

$c->finalize_body¶

Finalizes body.

$c->finalize_cookies¶

Finalizes cookies.

$c->finalize_error¶

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).

$c->finalize_headers¶

Finalizes headers.

$c->finalize_encoding¶

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::Response are available).

See "ENCODING".

$c->finalize_output¶

An alias for finalize_body.

$c->finalize_read¶

Finalizes the input after reading is complete.

$c->finalize_uploads¶

Finalizes uploads. Cleans up any temporary files.

$c->get_action( $action, $namespace )¶

Gets an action in a given namespace.

$c->get_actions( $action, $namespace )¶

Gets all actions of a given name in a namespace and all parent namespaces.

$app->handle_request( @arguments )¶

Called to handle each HTTP request.

$class->prepare( @arguments )¶

Creates a Catalyst context from an engine-specific request (Apache, CGI, etc.).

$c->prepare_action¶

Prepares action. See Catalyst::Dispatcher.

$c->prepare_body¶

Prepares message body.

$c->prepare_body_chunk( $chunk )¶

Prepares a chunk of data before sending it to HTTP::Body.

See Catalyst::Engine.

$c->prepare_body_parameters¶

Prepares body parameters.

$c->prepare_connection¶

Prepares connection.

$c->prepare_cookies¶

Prepares cookies by ensuring that the attribute on the request object has been built.

$c->prepare_headers¶

Prepares request headers by ensuring that the attribute on the request object has been built.

$c->prepare_parameters¶

Prepares parameters.

$c->prepare_path¶

Prepares path and base.

$c->prepare_query_parameters¶

Prepares query parameters.

$c->log_request¶

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

$c->log_response¶

Writes information about the response to the debug logs by calling "$c->log_response_status_line" and "$c->log_response_headers".

$c->log_response_status_line($response)¶

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)

$c->log_response_headers($headers);¶

Hook method which can be wrapped by plugins to log the response headers. No-op in the default implementation.

$c->log_request_parameters( query => {}, body => {} )¶

Logs request parameters to debug logs

$c->log_request_uploads¶

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.

$c->log_request_headers($headers);¶

Hook method which can be wrapped by plugins to log the request headers. No-op in the default implementation.

$c->log_headers($type => $headers)¶

Logs HTTP::Headers (either request or response) to the debug logs.

$c->prepare_read¶

Prepares the input for reading.

$c->prepare_request¶

Prepares the engine request.

$c->prepare_uploads¶

Prepares uploads.

$c->prepare_write¶

Prepares the output for writing.

$c->request_class¶

Returns or sets the request class. Defaults to Catalyst::Request.

$app->request_class_traits¶

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.

$app->composed_request_class¶

This is the request class which has been composed with any request_class_traits.

$c->response_class¶

Returns or sets the response class. Defaults to Catalyst::Response.

$app->response_class_traits¶

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.

$app->composed_response_class¶

This is the request class which has been composed with any response_class_traits.

$c->read( [$maxlength] )¶

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.

$c->run¶

Starts the engine.

$c->set_action( $action, $code, $namespace, $attrs )¶

Sets an action in a given namespace.

$c->setup_actions($component)¶

Sets up actions for a component.

$c->setup_components¶

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.

$app->setup_injected_components¶

Called by setup_compoents to setup components that are injected.

$app->setup_injected_component( $injected_component_name, $config )¶

Setup a given injected component.

$app->inject_component($MyApp_Component_name => \%args);¶

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'],
      });

$app->inject_components¶

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'],
      });

$c->locate_components( $setup_component_config )¶

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 named "search_extra" as an array reference. Items in the array beginning with "::" will have the application class name prepended to them.

$c->expand_component_module( $component, $setup_component_config )¶

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.

$app->delayed_setup_component¶

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.

$c->setup_component¶

$app->config_for( $component_name )¶

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.

$c->setup_dispatcher¶

Sets up dispatcher.

$c->setup_engine¶

Sets up engine.

$c->apply_default_middlewares¶

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.

App->psgi_app¶

App->to_app¶

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.

$c->setup_home¶

Sets up the home directory.

$c->setup_encoding¶

Sets up the input/output encoding. See ENCODING

handle_unicode_encoding_exception¶

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;
    }

<B>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.

$c->setup_log¶

Sets up log by instantiating a Catalyst::Log object and passing it to log(). Pass in a comma-delimited list of levels to set the log to.

This method also installs a "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.

Note that if the log has already been setup, by either a previous call to "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¶

Sets up plugins.

$c->setup_stats¶

Sets up timing statistics class.

$c->registered_plugins¶

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 "Catalyst::Plugin::".

 if ($c->registered_plugins('Some::Plugin')) {
     ...
 }

default_middleware¶

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 "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.)

The current default middleware list is:

      Catalyst::Middleware::Stash
      Plack::Middleware::HTTPExceptions
      Plack::Middleware::RemoveRedundantBody
      Plack::Middleware::FixMissingBodyInRedirect
      Plack::Middleware::ContentLength
      Plack::Middleware::MethodOverride
      Plack::Middleware::Head

If the configuration setting "using_frontend_proxy" is true we add:

      Plack::Middleware::ReverseProxy

If the configuration setting "using_frontend_proxy_path" is true we add:

      Plack::Middleware::ReverseProxyPath

But NOTE that Plack::Middleware::ReverseProxyPath is not a dependency of the Catalyst 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.

registered_middlewares¶

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

setup_middleware (?@middleware)¶

Read configuration information stored in configuration key "psgi_middleware" or from passed @args.

See under "CONFIGURATION" information regarding "psgi_middleware" and how to use it to enable Plack::Middleware

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:

    package MyApp;
    use Catalyst;
    __PACKAGE__->setup_middleware('Head');
    __PACKAGE__->setup;

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 plugin Catalyst::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.

registered_data_handlers¶

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.

setup_data_handlers (?@data_handler)¶

Read configuration information stored in configuration key "data_handlers" or from passed @args.

See under "CONFIGURATION" information regarding "data_handlers".

This method is automatically called during 'setup' of your application, so you really don't need to invoke it.

default_data_handlers¶

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 via CGI::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 to JSON::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.)

$c->stack¶

Returns an arrayref of the internal execution stack (actions that are currently executing).

$c->stats¶

Returns the current timing statistics object. By default Catalyst uses Catalyst::Stats, but can be set otherwise with stats_class.

Even if -Stats is not enabled, the stats object is still available. By enabling it with "$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¶

Returns or sets the stats (timing statistics) class. Catalyst::Stats is used by default.

$app->stats_class_traits¶

A arrayref of Moose::Roles that are applied to the stats_class before creating it.

$app->composed_stats_class¶

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.

    $MyApp::TraitFor::Stats::$trait_suffix
    Catalyst::TraitFor::Stats::$trait_suffix

So for example if you set:

    MyApp->stats_class_traits(['Foo']);

We try each possible role in turn (and throw an error if none load)

    Foo
    MyApp::TraitFor::Stats::Foo
    Catalyst::TraitFor::Stats::Foo

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.

$c->use_stats¶

Returns 1 when stats collection is enabled.

Note that this is a static method, not an accessor and should be overridden by declaring "sub use_stats { 1 }" in your MyApp.pm, not by calling "$c->use_stats(1)".

$c->write( $data )¶

Writes $data to the output stream. When using this method directly, you will need to manually set the "Content-Length" header to the length of your output data, if known.

version¶

Returns the Catalyst version number. Mostly useful for "powered by" messages in template systems.

Note about psgi files¶

Note that if you supply your own .psgi file, calling "MyApp->psgi_app(@_);", then this will not happen automatically.

You either need to apply Plack::Middleware::ReverseProxy yourself in your psgi, for example:

    builder {
        enable "Plack::Middleware::ReverseProxy";
        MyApp->psgi_app
    };

This will unconditionally add the ReverseProxy support, or you need to call "$app = MyApp->apply_default_middlewares($app)" (to conditionally apply the support depending upon your config).

See Catalyst::PSGI for more information.

Methods¶

encoding

Returns an instance of an "Encode" encoding

    print $c->encoding->name
    

handle_unicode_encoding_exception ($exception_context)

Method called when decoding process for a request fails.

An $exception_context hashref is provided to allow you to override the behaviour of your application when given data with incorrect encodings.

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 $exception_context hash are:

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.¶