=head1 DESCRIPTION
-This document provides an overview of the internals of Catalyst. As Catalyst
-is still developing rapidly details may become out of date.
+This document provides an 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.
-
=head2 Initialization
Catalyst initializes itself in two stages (I may be wrong in some of
=item 1
-When the Catalyst module is imported in the main application module it
-evaluates any options (C<-Debug>, C<-Engine=XXX>) and loads any specified
-plugins, making application module inherit from the plugin classes. It also
-sets up a default log object and ensures that the application module inherits
-from C<Catalyst> and from the selected specialized Engine module.
+When the Catalyst module is imported in the main application
+module it evaluates any options (C<-Debug>, C<-Engine=XXX>)
+and loads any specified plugins, making the application module
+inherit from the plugin classes. It also sets up a default log
+object and ensures that the application module inherits from
+C<Catalyst> and from the selected specialized Engine module.
=item 2
When the application module makes the first call to C<< __PACKAGE__->action() >>
-(implemented in C<Catalyst::Engine>) Catalyst automatically loads all
-components it finds in the C<$class\::Controller>, C<$class\::C>,
-C<$class\::Model>, C<$class\::M>, C<$class\::View> and C<$class\::V>
+(implemented in C<Catalyst::Engine>), Catalyst automatically loads all
+components it finds in the C<$class::Controller>, C<$class::C>,
+C<$class::Model>, C<$class::M>, C<$class::View> and C<$class::V>
namespaces (using C<Module::Pluggable::Fast>). A table of actions is built up
and added to on subsequent calls to C<action()>.
=head2 Request Lifecycle
For each request Catalyst builds a I<context> object, which includes
-information about the request, and searches the action table for matching
+information about the request, and then searches the action table for matching
actions.
The handling of a request can be divided into three stages: preparation of the
are the steps of a Catalyst request in detail; every step can be overloaded to
extend Catalyst.
- handler
+ handle_request
prepare
prepare_request
- prepare_path
- prepare_cookies
- prepare_headers
prepare_connection
+ prepare_query_parameters
+ prepare_headers
+ prepare_cookies
+ prepare_path
+ prepare_body (unless parse_on_demand)
+ prepare_body_parameters
+ prepare_parameters
+ prepare_uploads
prepare_action
- prepare_parameters
- prepare_uploads
- process
+ dispatch
finalize
+ finalize_uploads
+ finalize_error (if one happened)
finalize_headers
- finalize_output
+ finalize_cookies
+ finalize_body
These steps are normally overloaded from engine classes, and may also be
extended by plugins. Extending means using multiple inheritance with L<NEXT>.