Manual Reference Pages - CATALYST::MANUAL::INTERNALS (3)
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 hasnt 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 components configuration. It then returns
an instance of the component, which becomes the $self when methods in
that component are called later.
Each controller has its 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
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 Catalyst::Manual::ExtendingCatalyst.
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.
|perl v5.20.3 ||CATALYST::MANUAL::INTERNALS (3) ||2014-12-13 |
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.