This file is indexed.

/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