X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FInternals.pod;h=b8083c96bb54401161dac2ecdf0532fa5b51641f;hp=41efa22f33a6cfbe1152f6bf9ce2d64d7b921131;hb=e8200f38d465b85ad84eb11718db1e61230ce73b;hpb=cb93c9d7a46377666f9593736dcb87fad8f9d82e diff --git a/lib/Catalyst/Manual/Internals.pod b/lib/Catalyst/Manual/Internals.pod index 41efa22..b8083c9 100644 --- a/lib/Catalyst/Manual/Internals.pod +++ b/lib/Catalyst/Manual/Internals.pod @@ -4,7 +4,7 @@ Catalyst::Manual::Internals - Catalyst Internals =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. @@ -13,37 +13,52 @@ The coverage is split into initialization and request lifecycle. =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 (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 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 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). A table of actions is built up -and added to on subsequent calls to C. +namespaces (using C). As each is loaded, if it has a +L 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 method called. At this point, +the subroutine attributes are retrieved from the +L, parsed, and used to +build instances of L, which are then registered with +the dispatcher. + +=back =head2 Request Lifecycle For each request Catalyst builds a I 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 @@ -72,19 +87,20 @@ extend Catalyst. finalize_body These steps are normally overloaded from engine classes, and may also be -extended by plugins. Extending means using multiple inheritance with L. +extended by plugins. For more on extending Catalyst, see L. -The specialized engine classes populate the Catalyst request object with -information from the underlying layer (C or C) +The engine class populates the Catalyst request object with +information from the underlying layer (L) 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 +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