Catalyst::Manual::Internals - Catalyst Internals
This document provides a brief overview of the internals of Catalyst. As
Catalyst is still developing rapidly, details may become out of date: please
treat this as a guide, and look at the source for the last word.
The coverage is split into initialization and request lifecycle.
Catalyst initializes itself in two stages:
- When the Catalyst module is imported in the main
application module, it stores any options.
- When "__PACKAGE__->setup" is called, it
evaluates any options stored ("-Debug"), and makes the
application inherit from Catalyst (if that hasn't already been done with
an explicit "use base 'Catalyst';" or "extends
'Catalyst';". Any specified plugins are then loaded, the application
module is made to inherit from the plugin classes. It also sets up a
default log object and ensures that the application module inherits from
"Catalyst" and from the selected specialized Engine module.
- Catalyst automatically loads all components it finds in the
$class::Controller, $class::C, $class::Model, $class::M, $class::View and
$class::V namespaces (using "Module::Pluggable"). As each is
loaded, if it has a COMPONENT method then this method will be called, and
passed that component's configuration. It then returns an instance of the
component, which becomes the $self when methods in that component are
- Each controller has it's "register_actions"
method called. At this point, the subroutine attributes are retrieved from
the MooseX::MethodAttributes::Role::Meta::Map, parsed, and used to build
instances of Catalyst::Action, which are then registered with the
For each request Catalyst builds a context
object, which includes
information about the request, and then searches the action table for matching
The handling of a request can be divided into three stages: preparation of the
context, processing of the request, and finalization of the response. These
are the steps of a Catalyst request in detail; every step can be overloaded to
prepare_body (unless parse_on_demand)
finalize_error (if one happened)
These steps are normally overloaded from engine classes, and may also be
extended by plugins. For more on extending Catalyst, see
The engine class populates the Catalyst request object with information from the
underlying layer (PSGI) during the prepare phase, then push the generated
response information down to the underlying layer during the finalize phase.
Catalyst Contributors, see Catalyst.pm
This library is free software. You can redistribute it and/or modify it under
the same terms as Perl itself.