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=459518f80f0213959ec0398b3a0fa1146b059757;hp=e7aaace4b19fdab5df287ce07f5842c21c90db9e;hb=e0dfa383e8f431b273c2696f86938c1cbeb7ab42;hpb=9a4214e19f018d581fdec224e13e83ef1b74c3b5

diff --git a/lib/Catalyst/Manual/Internals.pod b/lib/Catalyst/Manual/Internals.pod
index e7aaace..459518f 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>), 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>).  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
@@ -73,17 +90,18 @@ extend Catalyst.
 These steps are normally overloaded from engine classes, and may also be
 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