Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

catalyst::manual::writingplugins(3pm) [debian man page]

Catalyst::Manual::WritingPlugins(3pm)			User Contributed Perl Documentation		     Catalyst::Manual::WritingPlugins(3pm)

NAME
Catalyst::Manual::WritingPlugins - DEPRECATED, see Catalyst::Manual::ExtendingCatalyst instead SEE INSTEAD
This document is now deprecated. Please refer to Catalyst::Manual::ExtendingCatalyst for information on how to extend the framework and your applications. AUTHORS
Catalyst Contributors, see Catalyst.pm COPYRIGHT
This library is free software. You can redistribute it and/or modify it under the same terms as Perl itself. perl v5.14.2 2012-01-20 Catalyst::Manual::WritingPlugins(3pm)

Check Out this Related Man Page

Catalyst::Manual::Internals(3pm)			User Contributed Perl Documentation			  Catalyst::Manual::Internals(3pm)

NAME
Catalyst::Manual::Internals - Catalyst Internals 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. Initialization Catalyst initializes itself in two stages: 1. When the Catalyst module is imported in the main application module, it stores any options. 2. When "__PACKAGE__->setup" is called, it evaluates any options stored ("-Debug"), and makes the application inherit from Catalyst (if that hasn't already been done with an explicit "use base 'Catalyst';" or "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 "Catalyst" and from the selected specialized Engine module. 3. Catalyst automatically loads all components it finds in the $class::Controller, $class::C, $class::Model, $class::M, $class::View and $class::V namespaces (using "Module::Pluggable"). As each is loaded, if it has a 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 $self when methods in that component are called later. 4. Each controller has it's "register_actions" method called. At this point, the subroutine attributes are retrieved from the MooseX::MethodAttributes::Role::Meta::Map, parsed, and used to build instances of Catalyst::Action, which are then registered with the dispatcher. Request Lifecycle For each request Catalyst builds a 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 Catalyst::Manual::ExtendingCatalyst. The engine class populate sthe Catalyst request object with information from the underlying layer (PSGI) during the prepare phase, then push the generated response information down to the underlying layer during the finalize phase. AUTHORS
Catalyst Contributors, see Catalyst.pm COPYRIGHT
This library is free software. You can redistribute it and/or modify it under the same terms as Perl itself. perl v5.14.2 2012-01-20 Catalyst::Manual::Internals(3pm)
Man Page