1Catalyst::Manual::InterUnsaelrs(C3o)ntributed Perl DocumCeanttaaltyisotn::Manual::Internals(3)
2
3
4
6 Catalyst::Manual::Internals - Catalyst Internals
7
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", "-Engine=XXX"), and makes the application inherit
24 from Catalyst (if that hasn't already been done with an explicit
25 "use base 'Catalyst';" or "extends 'Catalyst';". Any specified
26 plugins are then loaded, the application module is made to inherit
27 from the plugin classes. It also sets up a default log object and
28 ensures that the application module inherits from "Catalyst" and
29 from the 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").
34 As each is loaded, if it has a Catalyst::Component/COMPONENT method
35 then this method will be called, and passed that component's
36 configuration. It then returns an instance of the component, which
37 becomes the $self when 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
41 MooseX::MethodAttributes::Role::Meta::Map, parsed, and used to
42 build instances of Catalyst::Action, which are then registered with
43 the dispatcher.
44
45 Request Lifecycle
46 For each request Catalyst builds a context object, which includes
47 information about the request, and then searches the action table for
48 matching actions.
49
50 The handling of a request can be divided into three stages: preparation
51 of the context, processing of the request, and finalization of the
52 response. These are the steps of a Catalyst request in detail; every
53 step can be overloaded to extend Catalyst.
54
55 handle_request
56 prepare
57 prepare_request
58 prepare_connection
59 prepare_query_parameters
60 prepare_headers
61 prepare_cookies
62 prepare_path
63 prepare_body (unless parse_on_demand)
64 prepare_body_parameters
65 prepare_parameters
66 prepare_uploads
67 prepare_action
68 dispatch
69 finalize
70 finalize_uploads
71 finalize_error (if one happened)
72 finalize_headers
73 finalize_cookies
74 finalize_body
75
76 These steps are normally overloaded from engine classes, and may also
77 be extended by plugins. For more on extending Catalyst, see
78 Catalyst::Manual::ExtendingCatalyst.
79
80 The specialized engine classes populate the Catalyst request object
81 with information from the underlying layer ("Apache::Request" or
82 "CGI::Simple") during the prepare phase, then push the generated
83 response information down to the underlying layer during the finalize
84 phase.
85
87 Catalyst Contributors, see Catalyst.pm
88
90 This library is free software. You can redistribute it and/or modify it
91 under the same terms as Perl itself.
92
93
94
95perl v5.12.0 2009-11-15 Catalyst::Manual::Internals(3)