Moving Catalyst::Manual from Catalyst-Runtime to Catalyst-Manual dist

[catagits/Catalyst-Runtime.git] / lib / Catalyst / Manual / Internals.pod

diff --git a/lib/Catalyst/Manual/Internals.pod b/lib/Catalyst/Manual/Internals.pod
deleted file mode 100644 (file)
index 41efa22..0000000
--- a/lib/Catalyst/Manual/Internals.pod
+++ /dev/null
@@ -1,90 +0,0 @@
-=head1 NAME
-
-Catalyst::Manual::Internals - Catalyst Internals
-
-=head1 DESCRIPTION
-
-This document provides an 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.
-
-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):
-
-=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
-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
-
-When the application module makes the first call to C<< __PACKAGE__->action() >>
-(implemented in C<Catalyst::Engine>), 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()>.
-
-=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.  
-
-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
-are the steps of a Catalyst request in detail; every step can be overloaded to
-extend Catalyst.
-
-    handle_request
-      prepare
-        prepare_request
-        prepare_connection
-        prepare_query_parameters
-        prepare_headers
-        prepare_cookies
-        prepare_path
-        prepare_body (unless parse_on_demand)
-          prepare_body_parameters
-          prepare_parameters
-          prepare_uploads
-        prepare_action
-      dispatch
-      finalize
-        finalize_uploads
-        finalize_error (if one happened)
-        finalize_headers
-          finalize_cookies
-        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>.
-
-The specialized engine classes populate the Catalyst request object with
-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>
-
-=head1 COPYRIGHT
-
-This program is free software, you can redistribute it and/or modify it under
-the same terms as Perl itself.