1Catalyst::Manual::InterUnsaelrs(C3o)ntributed Perl DocumCeanttaaltyisotn::Manual::Internals(3)
2
3
4

NAME

6       Catalyst::Manual::Internals - Catalyst Internals
7

DESCRIPTION

9       This document provides a brief overview of the internals of Catalyst.
10       As Catalyst is still developing rapidly, details may become out of
11       date: please treat this as a guide, and look at the source for the last
12       word.
13
14       The coverage is split into initialization and request lifecycle.
15
16   Initialization
17       Catalyst initializes itself in two stages:
18
19       1.  When the Catalyst module is imported in the main application
20           module, it stores any options.
21
22       2.  When "__PACKAGE__->setup" is called, it evaluates any options
23           stored ("-Debug"), and makes the application inherit from Catalyst
24           (if that hasn't already been done with an explicit "use base
25           'Catalyst';" or "extends 'Catalyst';".  Any specified plugins are
26           then loaded, the application module is made to inherit from the
27           plugin classes. It also sets up a default log object and ensures
28           that the application module inherits from "Catalyst" and from the
29           selected specialized Engine module.
30
31       3.  Catalyst automatically loads all components it finds in the
32           $class::Controller, $class::C, $class::Model, $class::M,
33           $class::View and $class::V namespaces (using Module::Pluggable). As
34           each is loaded, if it has a COMPONENT method then this method will
35           be called, and passed that component's configuration. It then
36           returns an instance of the component, which becomes the $self when
37           methods in that component are called later.
38
39       4.  Each controller has it's "register_actions" method called. At this
40           point, the subroutine attributes are retrieved from the metaclass,
41           parsed, and used to build instances of Catalyst::Action, which are
42           then registered with the dispatcher.
43
44   Request Lifecycle
45       For each request Catalyst builds a context object, which includes
46       information about the request, and then searches the action table for
47       matching actions.
48
49       The handling of a request can be divided into three stages: preparation
50       of the context, processing of the request, and finalization of the
51       response.  These are the steps of a Catalyst request in detail; every
52       step can be overloaded to extend Catalyst.
53
54           handle_request
55             prepare
56               prepare_request
57               prepare_connection
58               prepare_query_parameters
59               prepare_headers
60               prepare_cookies
61               prepare_path
62               prepare_body (unless parse_on_demand)
63                 prepare_body_parameters
64                 prepare_parameters
65                 prepare_uploads
66               prepare_action
67             dispatch
68             finalize
69               finalize_uploads
70               finalize_error (if one happened)
71               finalize_headers
72                 finalize_cookies
73               finalize_body
74
75       These steps are normally overloaded from engine classes, and may also
76       be extended by plugins. For more on extending Catalyst, see
77       Catalyst::Manual::ExtendingCatalyst.
78
79       The engine class populates the Catalyst request object with information
80       from the underlying layer (PSGI) during the prepare phase, then push
81       the generated response information down to the underlying layer during
82       the finalize phase.
83

AUTHORS

85       Catalyst Contributors, see Catalyst.pm
86

88       This library is free software. You can redistribute it and/or modify it
89       under the same terms as Perl itself.
90
91
92
93perl v5.36.0                      2023-01-20    Catalyst::Manual::Internals(3)
Impressum