/usr/share/perl5/Catalyst/Manual/Internals.pod is in libcatalyst-manual-perl 5.9009-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 | =head1 NAME
Catalyst::Manual::Internals - Catalyst Internals
=head1 DESCRIPTION
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.
The coverage is split into initialization and request lifecycle.
=head2 Initialization
Catalyst initializes itself in two stages:
=over 4
=item 1
When the Catalyst module is imported in the main application
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 3
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>). 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.
=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.
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. For more on extending Catalyst, see L<Catalyst::Manual::ExtendingCatalyst>.
The engine class populates the 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
Catalyst Contributors, see Catalyst.pm
=head1 COPYRIGHT
This library is free software. You can redistribute it and/or modify it under
the same terms as Perl itself.
=cut
|