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=9263addd081278b83b0dd009dea714657fb23c3c;hp=41efa22f33a6cfbe1152f6bf9ce2d64d7b921131;hb=33f1d5d0f724ce2cc6e8d5da5ea36735ecd069d0;hpb=cb93c9d7a46377666f9593736dcb87fad8f9d82e diff --git a/lib/Catalyst/Manual/Internals.pod b/lib/Catalyst/Manual/Internals.pod index 41efa22..9263add 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,53 @@ 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>, C<-Engine=XXX>), 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 +88,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) 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