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=0ad159bd79ac136dd27ec68c6006053407413323;hp=e7aaace4b19fdab5df287ce07f5842c21c90db9e;hb=b1a08fe19fd4ce1cd7756727319d08156b1e563f;hpb=51cafe14b695800eda56f10e227b6adcc182ce88

diff --git a/lib/Catalyst/Manual/Internals.pod b/lib/Catalyst/Manual/Internals.pod
index e7aaace..0ad159b 100644
--- a/lib/Catalyst/Manual/Internals.pod
+++ b/lib/Catalyst/Manual/Internals.pod
@@ -20,29 +20,46 @@ Catalyst initializes itself in two stages:
 =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>), 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>).  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<Catalyst::Component/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
@@ -78,7 +95,6 @@ information from the underlying layer (C<Apache::Request> or C<CGI::Simple>)
 during the prepare phase, then push the generated response information down to
 the underlying layer during the finalize phase.
 
-
 =head1 AUTHOR
 
 Sebastian Riedel, C<sri@oook.de>
@@ -87,3 +103,4 @@ Sebastian Riedel, C<sri@oook.de>
 
 This program is free software, you can redistribute it and/or modify it under
 the same terms as Perl itself.
+