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

=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 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>).  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. For more on extending Catalyst, see L<Catalyst::Manual::ExtendingCatalyst>.

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.
Commit	Line	Data
cb93c9d7	1	=head1 NAME
	2
	3	Catalyst::Manual::Internals - Catalyst Internals
	4
	5	=head1 DESCRIPTION
	6
9a4214e1	7	This document provides a brief overview of the internals of
cb93c9d7	8	Catalyst. As Catalyst is still developing rapidly, details
	9	may become out of date: please treat this as a guide, and
	10	look at the source for the last word.
	11
	12	The coverage is split into initialization and request lifecycle.
	13
	14	=head2 Initialization
	15
9a4214e1	16	Catalyst initializes itself in two stages:
cb93c9d7	17
	18	=over 4
	19
	20	=item 1
	21
	22	When the Catalyst module is imported in the main application
	23	module it evaluates any options (C<-Debug>, C<-Engine=XXX>)
	24	and loads any specified plugins, making the application module
	25	inherit from the plugin classes. It also sets up a default log
	26	object and ensures that the application module inherits from
	27	C<Catalyst> and from the selected specialized Engine module.
	28
	29	=item 2
	30
	31	When the application module makes the first call to C<< __PACKAGE__->action() >>
	32	(implemented in C<Catalyst::Engine>), Catalyst automatically loads all
	33	components it finds in the C<$class::Controller>, C<$class::C>,
	34	C<$class::Model>, C<$class::M>, C<$class::View> and C<$class::V>
9a4214e1	35	namespaces (using C<Module::Pluggable>). A table of actions is built up
cb93c9d7	36	and added to on subsequent calls to C<action()>.
	37
	38	=back
	39
	40
	41	=head2 Request Lifecycle
	42
	43	For each request Catalyst builds a I<context> object, which includes
	44	information about the request, and then searches the action table for matching
	45	actions.
	46
	47	The handling of a request can be divided into three stages: preparation of the
	48	context, processing of the request, and finalization of the response. These
	49	are the steps of a Catalyst request in detail; every step can be overloaded to
	50	extend Catalyst.
	51
	52	handle_request
	53	prepare
	54	prepare_request
	55	prepare_connection
	56	prepare_query_parameters
	57	prepare_headers
	58	prepare_cookies
	59	prepare_path
	60	prepare_body (unless parse_on_demand)
	61	prepare_body_parameters
	62	prepare_parameters
	63	prepare_uploads
	64	prepare_action
	65	dispatch
	66	finalize
	67	finalize_uploads
	68	finalize_error (if one happened)
	69	finalize_headers
	70	finalize_cookies
	71	finalize_body
	72
	73	These steps are normally overloaded from engine classes, and may also be
9a4214e1	74	extended by plugins. For more on extending Catalyst, see L<Catalyst::Manual::ExtendingCatalyst>.
cb93c9d7	75
	76	The specialized engine classes populate the Catalyst request object with
	77	information from the underlying layer (C<Apache::Request> or C<CGI::Simple>)
	78	during the prepare phase, then push the generated response information down to
	79	the underlying layer during the finalize phase.
	80
	81
	82	=head1 AUTHOR
	83
	84	Sebastian Riedel, C<sri@oook.de>
	85
	86	=head1 COPYRIGHT
	87
	88	This program is free software, you can redistribute it and/or modify it under
	89	the same terms as Perl itself.