=head1 DESCRIPTION
-This document provides an overview of the internals of
+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.
=head2 Initialization
-Catalyst initializes itself in two stages (I may be wrong in some of
-the details here - AF):
+Catalyst initializes itself in two stages:
=over 4
=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 the application module
+module, it stores any options.
+
+
+=item 2
+
+When C<< __PACKAGE__->setup >> is called, it evaluates any
+options stored (C<-Debug>), and makes the application
+inherit from L<Catalyst> (if that hasn't already been done with an
+explicit C<< use base 'Catalyst'; >> or C<< 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
C<Catalyst> and from the selected specialized Engine module.
-=item 2
+=item 3
-When the application module makes the first call to C<< __PACKAGE__->action() >>
-(implemented in C<Catalyst::Engine>), Catalyst automatically loads all
+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()>.
+namespaces (using C<Module::Pluggable>). As each is loaded, if it has a
+L<COMPONENT|Catalyst::Component/"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 C<$self> when methods in
+that component are called later.
-=back
+=item 4
+
+Each controller has it's C<register_actions> method called. At this point,
+the subroutine attributes are retrieved from the
+L<MooseX::MethodAttributes::Role::Meta::Map|metaclass>, parsed, and used to
+build instances of L<Catalyst::Action>, which are then registered with
+the dispatcher.
+=back
=head2 Request Lifecycle
For each request Catalyst builds a I<context> object, which includes
information about the request, and then searches the action table for matching
-actions.
+actions.
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
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>.
+extended by plugins. For more on extending Catalyst, see L<Catalyst::Manual::ExtendingCatalyst>.
-The specialized engine classes populate the Catalyst request object with
-information from the underlying layer (C<Apache::Request> or C<CGI::Simple>)
+The engine class populate sthe Catalyst request object with
+information from the underlying layer (L<PSGI>)
during the prepare phase, then push the generated response information down to
the underlying layer during the finalize phase.
+=head1 AUTHORS
-=head1 AUTHOR
-
-Sebastian Riedel, C<sri@oook.de>
+Catalyst Contributors, see Catalyst.pm
=head1 COPYRIGHT
-This program is free software, you can redistribute it and/or modify it under
+This library is free software. You can redistribute it and/or modify it under
the same terms as Perl itself.
+
+=cut
projects / catagits/Catalyst-Manual.git / blobdiff