Catalyst

Catalyst - это MVC Фреймворк для разработки веб-приложений


Создание нового проекта

Процесс создание проекта происходит с помощью различных модулей, не требующих непременного запуска, которые являются полезными для разработки Catalyst приложений, с целью упрощения рутинных процедур, таких как создание папок, файлов, комментариев к ним и т.д. Общее название этих модулей "Catalyst::Devel", которые включают Catalyst::Helper систему, которая собственно автоматически генерирует необходимые скрипты и тесты; модуль Module::Install::Catalyst, это расширение для Catalyst; которые требуются для различных разрабатываемых и связанных между собой модулей.

Создание проекта выполняется следующей командой:
catalyst.pl MyApp

Добавление моделей, видов и контроллеров:

script/myapp_create.pl model MyDatabase DBIC::Schema create=static db i:SQLite:/path/to/db

script/myapp_create.pl view MyTemplate TT

script/myapp_create.pl controller Search

Запуск тестового сервера -- если использовать аттрибут -r то он будет, автоматически перезагружаться, когда будут происходить изменения в файлах, во время разработки: script/myapp_server.pl

Тестирование интерфейса:
script/myapp_test.pl /yada

Пример работы проекта

В файле lib/MyApp.pm добавляем плагины:
use Catalyst qw/-Debug/;



В сгенерированном файле lib/MyApp/Controller/Root.pm.

sub foo : Chained('/') Args() { 
  # вызов для /foo, /foo/1, /foo/1/2, и т.д.
   my ( $self, $c, @args ) = @_; # аргументы qw/1 2/ для /foo/1/2
   $c->stash->{template} = 'foo.tt'; # устанавливаем шаблон
   # ищем в бд -- stash пригодная для TT
   $c->stash->{data} =$c->model('Database::Foo')->search({country =>$args[0]});
   if ( $c->req->params->{bar} ) { # access GET or POST parameters
     $c->forward('bar'); # вызов другого действия
     # продолжаем выполнение метода, как только bar возвратит значение
   }
}

Файл foo.tt TT шаблон может использовать stash данные из базы данных

[% WHILE (item = data.next) %]
[% item.foo %]
[% END %]

# вызов для /bar/of/soap, /bar/of/soap/10, и т.д.
sub bar : Chained('/') PathPart('/bar/of/soap') Args() { ... }

# вызывается после всех действий и заканчивается
sub end : Action {
   my ( $self, $c ) = @_;
   if ( scalar @{ $c->error } ) { ... } # обработка ошибок
     return if $c->res->body; # уже есть ответ
     $c->forward( 'MyApp::View::TT' ); # создаем шаблон
}


Настройка проекта


Catalyst плагины могут быть загружены с помощью:
use Catalyst qw/My::Module/;
но если имя плагина начинается не с "Catalyst::Plugin" вам нужно указать полное имя плагина, предварив его знаком "+"

use Catalyst qw/
   My::Module
   +Fully::Qualified::Plugin::Name
/;
Специальный флаг как например "-Debug" может быть также объявлен как аргумент когда Catalyst загружен:
use Catalyst qw/-Debug My::Module/;

Позиция плагинов и флагов важна, потому что они загружатся в том порядке, в каком они были указаны.

Поддерживаемые флаги:
-Debug
Позволяет выводить информацию об отладке. Вы также может принудительно установить эту настройку из переменных окружения с помощью CATALYST_DEBUG или <MYAPP>_DEBUG. Эти переменные перезаписывают, установленные настройки в приложении, <MYAPP>_DEBUG имеет наивысший приоритет.
Это устанавливает уровень отладки и позволяет выводить полную отладочную информацию на экран ошибки. Если хотите сделать позже, смотрите $c->debug.

-Home
Принуждает Catalyst использовать заданную домашнюю папку, например:
use Catalyst qw[-Home=/usr/mst];
Так же эту переменную можно установить из консоли с помощью CATALYST_HOME или MYAPP_HOME, где MYAPP название приложения в верхнем регистре, "::" заменяются на "_". У MYAPP_HOME приоритет выше.
Если эти переменные не определены Catalyst пробует автоматически определить домашнюю директорию. Если вы работает в среде разработки, Catalyst попытается найти директорию, содержащую файлы Makefile.PL, Build.PL или dist.ini. Если приложение установленно в систему, (make install) , тогда Catalyst будет использовать к вашему модулю приложений, без .pm расширения (например, /foo/MyApp если приложение установлено в /foo/MyApp.pm).

-Log
use Catalyst '-Log=warn,fatal,error';

-Stats
Активирует статистику коллекций и отчетов.
use Catalyst qw/-Stats=1/;
Или с помощью переменных CATALYST_STATS или <MYAPP>_STATS (наивысишй приоритет).
Stats также доступен если установлен режим отладки.




Методы

Информация о текущем запросе


$c->action
Возвращает Catalyst::Action объект для текущего действия. См. Catalyst::Action.

$c->namespace
Возвращает пространство имен для текущего действия, т.е., URI префикс, соответсвующий контроллеру данного действия. Например:
# в Controller::Foo::Bar
$c->namespace; # возвращает 'foo/bar';

$c->request
$c->req
Возвращает текущий объект Catalyst::Request, предоставлящий доступ к информации о текущем клиентском запросе (включая параметры, куки, HTTP заголовки и т.д). См. Catalyst::Request.


Управление потоком запроса
$c->forward( $action [, \@arguments ] )
$c->forward( $class, $method, [, \@arguments ] )
Переадресовывает обработку другому действию, посредством приватного имени. Если вы даете имя класса но без метода, "process()" будет вызван. Вы можете также по выбору пройтись по аргументам в ссылке на массив. Action получит аргументы в переменной @_ и "$c->req->args". При возвращении из функции "$c->req->args" будут востановлены их предыдущие значения.
Всякие данные возвращенные из переадресованного действия, будут возвращены вызовом для переадресации.

my $foodata = $c->forward('/foo');
$c->forward('index');
$c->forward(qw/Model::DBIC::Foo do_stuff/);
$c->forward('View::TT');

Примечание что переадресация подразумевает "eval { }" около вызова (на самом деле выполняет его), таким образом рендеринг всех исключений через вызванный метод действия не фатален и все исключения помещаются в $c->error вместо этого. Если вы хотите "die" опубликовать, вам нужно сделать нечто подобное:
$c->forward('foo');
die join "\n", @{ $c->error } if @{ $c->error };

Или быть уверенными что все возвращенные истинные значени из ваших действий и написать примерно такой код:
$c->forward('foo') || return;

И еще "$c->forward" всегда возвращает скаляр, потому что фактически $c->state который действует в скалярном контексте. Таким образом, нечто подобное return @array; в действие, в которое было переадресовано, вернет это как скаляр. Если вам нужно вернуть массив, тогда возвратите ссылку на него, или stash делает это так:
$c->stash->{array} = \@array;

доступ к нему можно также получить через stash.

Держите это в уме, когда использует "end" метод, который вызывает действие. Итак "$c->detach" внутри переадресованного действия запустит "end" метод из оригинального запрошенного действия.


$c->detach( $action [, \@arguments ] )
$c->detach( $class, $method, [, \@arguments ] )
$c->detach()
Похож на forward, но не возвращает предыдущие действие когда процесс завершен. Когда вызывается без аргументов выходит цепь обработчиков полностью.


$c->visit( $action [, \@arguments ] )
$c->visit( $action [, \@captures, \@arguments ] )
$c->visit( $class, $method, [, \@arguments ] )
$c->visit( $class, $method, [, \@captures, \@arguments ] )
Почти такой же как forward, но выполняет полную отправку, взамен простого вызова нового действия $action / "$class->$method". Это означает, что "begin" и "auto" и метод который был вызван, просто напросто есть новый запрос.
В дополнении оба "$c->action" и "$c->namespace" локализованы. Это значит, для примера, что "$c->action" такие как имя, класс и ошибки возвращают информацию для посещенных действий, когда они были вызваны внутри посещенного действия. Это различие протекания процесса forward, который продолжает использовать $c->action объект из вызывавшего действия, даже когда вызван из именованного действия.
"$c->stash" остается неизменным.
В действительности, visit позволяет вам обернуть другой action. хорошо, что вызвано с помощью деспетчирования из URL, пока аналогичные переходы позволяют вам передавать контрол другому действию как будто это сделано напрямую из URL.


$c->go( $action [, \@arguments ] )
$c->go( $action [, \@captures, \@arguments ] )
$c->go( $class, $method, [, \@arguments ] )
$c->go( $class, $method, [, \@captures, \@arguments ] )
Отношение между "go" и visit такие же как отношения между forward и detach. Как "$c->visit", "$c->go", выполнят полный отправку объявленного действия или метода, с локализованными "$c->action" и "$c->namespace". Наподобие "detach", "go" выходит на обработку текущего запроса цепочки на завершение, и не возвращает своему вызывателю.
@arguments - аргументы конечного назначения $action. @captures - аргументы для промежуточных шагов, если это имеет место по пути завершения подпрограммы $action.

$c->response
$c->res
Возвращает текущий Catalyst::Response объект. см.подробнее.

$c->stash
Возвращает ссылку на хэш stash, которая может быть использована для хранения данных и передачи их между компонентами во время запроса. Вы можете также установить хеш ключей, для прогона аргументов. Stash автоматически устанавливает View. Stash очищается в конце запроса, и не может быть использован для постоянного хранения (для этого вы должны использовать сессию; см. Catalyst::Plugin::Session для завершения системной интеграции с Catalyst).
$c->stash->{foo} = $bar;
$c->stash( { moose => 'majestic', qux => 0 } );
$c->stash( bar => 1, gorch => 2 );

# stash автоматически устанавливает вид для использования в шаблоне
$c->forward( 'MyApp::View::TT' );


$c->error
$c->error($error, ...)
$c->error($arrayref)
Возвращает ссылку на массив с сообщениями об ошибках. Если Catalyst в процессе обработки запроса встретит ошибку, он помещает ее в $c->error. Этот метод следует использовать для хранения только фатальных ошибок.
my @error = @{ $c->error };

Добавление новой ошибки.
$c->error('Случилось что-то нехорошее');
$c->state
 
Содержит возвращенное значение последнего выполненного действия. Все значения - скаляр.

$c->clear_errors
Очищает ошибки. Вы вероятно не хотите очистить ошибки если вы не реализовали пользовательский экран ошибок.
Это эквивалентно запуску:
$c->error(0);


Доступы к компонентам


$c->controller($name)
Берет Catalyst::Controller экземпляр по имени.

$c->controller('Foo')->do_stuff;
Если имя пропущено, возвратит контроллер для диспетчиризации действия.
Если вы хотите найти контроллер, пройдетесь регулярным выражением в качестве аргумента.
my @foo_controllers = $c->controller(qr{^Foo});


$c->model($name)
Получает Catalyst::Model по имени.
$c->model('Foo')->do_stuff; 

Всякие расширенные аргументы прямо переадресовываются в ACCEPT_CONTEXT.
Если имя пропущено, будет искать:
- объект модели в $c->stash->{current_model_instance}, затем
- имя модели в $c->stash->{current_model}, затем
- конфиг настроек в 'default_model', или
- проверит если одна модель, то возвратит ее в этом случае.

Для поиска модели:
my @foo_models = $c->model(qr{^Foo});


$c->view($name)
Получает Catalyst::View по имени.
$c->view('Foo')->do_stuff;
Всякие расширеные аргументы прямо переадресовываются в ACCEPT_CONTEXT.
Если имя пропущено, будет искать:
- объект модели в $c->stash->{current_view_instance}, затем
- имя модели в $c->stash->{current_view}, затем
- конфиг настроек в 'default_view', или
- проверит если одна модель, то возвратит ее в этом случае.
my @foo_views = $c->view(qr{^Foo});


$c->controllers
Возвращает доступные имена которые можно использовать в $c->controller


$c->models
то же самое для $c->model

$c->views
то же самое для $c->view

$c->comp($name)
$c->component($name)
Получает объект по имени. Этот метод не рекомендуется если не хотите получать заданный класс по полному имени класса. "$c->controller", "$c->model", и "$c->view" следует использовать взамен.
Вместо имени можно использовать регулярные выражения, возвратит совпадения.
Если Catalyst не может найти компонент по имени, он отступит к совпадениям по регулярным выражениям по умолчанию. Для того что деактивировать это поведение установите disable_component_resolution_regex_fallback в истинное значение.
__PACKAGE__->config( disable_component_resolution_regex_fallback => 1 );



Данные класса и помощники классов

$c->config
Возвращает или берет ссылку на хэш содержащий конфигурацию приложения.

__PACKAGE__->config( { db => 'dsn:SQLite:foo.db' } );
Вы можете также использовать "YAML", "XML" или Config::General файл конфигурации вроде "myapp.conf" в ваше домашней папке приложения. См. Catalyst::Plugin::ConfigLoader.

Многоуровневая конфигурация

Метод конфигурации имеется на всех Catalyst компонентах, и конфигурации сливаются когда приложение стартует. Настройки загружаются с помощью Catalyst::Plugin::ConfigLoader который имеет приоритет над другими настройками в следующим за вашем верхнем уровне класса "MyApp". Эти две конфигурации сливаются и затем конфигурационные данные чьи ключи совпадают как имя компонента объединяются для этого компонента.
Конфигурация для компонента затем вносятся в "new" метод, когда компонент создается.

Например:
MyApp->config({ 'Model::Foo' => { bar => 'baz', overrides => 'me' } } );
MyApp::Model::Foo->config({ quux => 'frob', overrides => 'this' });

будет обозначать, что "MyApp::Model::Foo" получает следующие данные, когда создается:
MyApp::Model::Foo->new({
   bar => 'baz',
   quux => 'frob',
   overrides => 'me',
});

Общая практика использовать Moose атрибуты над полученным компонентом для доступа к конфигурационным знанчениям.

package MyApp::Model::Foo;
use Moose;
has 'bar' => (
   is => 'rw',
   isa => 'Str',
);

Позже вы можете получить доступ к значению 'baz' с помощью вызова $c->model('Foo')->bar (или $self->bar вместо кода в модели).

Примечание: вы не должны вызывать "$self->config" или "__PACKAGE__->config" как способ прочитать конфигурацию внутри вашего кода, так как это не даст вам корректных значений. Вы должны взять конфигурационные значения примененные для конструктора и использовать их взамен.



$c->log
Возвращает экземпляр журнала. Если уже не установлено это, Catalyst установит это с Catalyst::Log объектом. Для использования собственного класса логов, установите регистратор(Logger) c "__PACKAGE_->log" метод более важный для вызова "__PACKAGE__->setup".

__PACKAGE__->log(MyLogger->new);
__PACKAGE__->setup;

И позже:
$c->log->info( 'Now logging with my own logger!' );
Вашему логгеру следует реализовать методы описанные в Catalyst::Log.


$c->debug
Возвращает 1 если режим отладки установлен, 0 в противном случае.
Вы можете установить режим отладки несколькими способами:
При вызове myapp_server.pl с флагом -d.
С помощью переменной окружения MYAPP_DEBUG, или CATALYST_DEBUG
-Debug опция в вашем MyApp.pm
При объявлении "sub debug { 1 }" в вашем MyApp.pm

Первые три также устанавливают режим отладки.
Вызов "$c->debug(1)" такого эффекта не даст.
$c->dispatcher
Возвращает экземпляр диспетчера. См. Catalyst::Dispatcher.

$c->engine
Возвращает экземляр двигателя. См Catalyst::Engine.


Сервисные методы
$c->path_to(@path)
Объединяет @path c "$c->config->{home}" и возвращает Path::Class::Dir объект. Помните вы можете использовать это объект как имя файла, но иногда вам нужно будет подробно все указать вызовом "->stringify".
Пример:
$c->path_to( 'db', 'sqlite.db' );


MyApp->setup
Инициализирует dispatcher и engine, загружает плагины, модели, и компоненты контроллера. Вы может также объявить массив плагинов для загрузки здесь, если вы выберете не загружать их в "use Catalyst" линии.

MyApp->setup;
MyApp->setup(qw/-Debug/);
Примечание: Вам не следует обертывать этот метод с помощью измененных методов или плохие вещи случатся - оберните методом "setup_finalize" взамен.


$app->setup_finalize
Скрепляет модифицированные методы. Этот метод не делает ничего за исключением установки "setup_finished" доступа.
Применение метода для модификации "setup" метода не работает, потому что странные вещи делаются для установки плагинов.
Пример:
after setup_finalize => sub {
   my $app = shift;
   ## что то еще
};

$c->uri_for( $path?, @args?, \%query_values? )
$c->uri_for( $action, \@captures?, @args?, \%query_values? )
Создает абсолютный URI объект основанные на "\" приложения, предоставляет путь, и дополнительные аргументы и запрос параметров. Когда используете строку, предоставляет текстовый URI. Если вам нужно более гибкое чем это (т.е. опция для предоставления относительного URI) см Catalyst::Plugin::SmartURI.
Если безо всяких аргументов, то возвратит URI для текущего действия. Чтобы возвратить текущее действие и также предоставить @args используйте "$c->uri_for($c->action, @args)".
Если 1й аргумент строка, он берет как общий URI путь относительно "$c->namespace" (если это не начинается "/"). Затем объединяет с "$c->request->base"; любые аргументы @args добавляют как дополнительные пути к компонентам; и всякие %query_values будут добавлены как "?foo=bar" параметры.
Если первый аргумент Catalyst::Action изображает действие которое будет иметь свой путь решивший использовать "$c->dispatcher->uri_for_action". Опция "\@captures" аргумент, ссылка на массив позволяющий проходить захваченные переменные которые будут нужны для заполнения цепочки и регулярного выражения; одиножды путь решен, "uri_for" продолжает будто путь был предоставлен, добавляет всякие аргументы или параметры и создает абсолютный URI.

Сбор для текущего запроса может быть найден в "$c->request->captures", и действия могут быть разрешены используя "Catalyst::Controller->action_for($name)". Если имеете путь для приватное действие используйте "$c->uri_for_action" взамен.

# равнозначно $c->req->uri
$c->uri_for($c->action, $c->req->captures,
@{ $c->req->args }, $c->req->params);

# для Foo действия в Bar контроллере
$c->uri_for($c->controller('Bar')->action_for('Foo'));

# путь для статического ресурса
$c->uri_for('/static/images/logo.png');



$c->uri_for_action( $path, \@captures_and_args?, @args?, \%query_values? )
$c->uri_for_action( $action, \@captures_and_args?, @args?, \%query_values? )
$path
Приватный путь к Catalyst действию для которого вы хотите создать URI.
Сокращенный вызов для "$c->dispatcher->get_action_by_path($path)" и прохода результирующего действия и оставшихся аргументов в "$c->uri_for".
Вы может также посмотреть в Catalyst::Action объекте, в этом случае переходит "$c->uri_for".

Примечание, что хотя путь выглядит как URI который отправляется для нужного действия, это не URI, а внутренний путь к этому действию.

Для примера, если действия похоже на это:
package MyApp::Controller::Users;

sub lst : Path('the-list') {}

Вы можете использовать:
$c->uri_for_action('/users/lst')

и это создаст URI /users/the-list.


\@captures_and_args?
Опциональная ссылка на массив Captures (т.е. "<CaptureArgs или $c->"req->captures>) и аргументы к запросу. Обычно используется Catalyst::DispatchType::Chained для видоизменения всех параметров в URI.

@args?
Опциональный список расширенных аргументов - может быть подан в "\@captures_and_args?" ссылка на массив, или здесь - какой бы вы не выбрали это легче для вашего кода.
Ваше действие может не иметь аргументов(ноль), фиксированное или переменное количество аргументов (пример. Args(1) для фиксированного количества или Args() для переменного числа)..

\%query_values?
Опциональная ссылка на массив параметров запроса для добавления, например:
{foo => 'bar'}
сгенерирует
/rest/of/your/uri?foo=bar


$c->welcome_message
Возвращает Catalyst HTML страницу приветствия.

run_options
Содержит хэш опций годных для использования из приложения скрипта, включая оринальные ARGV полученных скриптом, обработанные значения из этого ARGV и всякие расширенные аргументы, которые не были обработаны.
Это может быть использовано для добавления пользовательских опций в ваши скрипты приложения и установки вашего приложения различных зависимостей на значение этих опций.


Внутренние методы

Эти методы не предназначены для использования конечными пользователями.

$c->context_class
Возвращает или устанавливает контекст класса.

$c->counter
Возвращает ссылку на хэш содержащую coderefs и число выполнений (необходимо для обнаружения глубокой рекурсии).

$c->depth
Возвращает количество действий на текущий внутренний стек выполнения.

$c->dispatch
Переадресует запрос действию.
$c->dispatcher_class
Возвращает или устанавливает класс диспетчеризации..

$c->dump_these
Возвращает список из 2-х элементов массива ссылок (имя, структура) пары которая будет сброшена на страницу ошибки в режим отладки.

$c->engine_class
Возвращает или устанавливает engine класс.

$c->execute( $class, $coderef )
Выполняет coderef во взятом классе и ловит исключения. Ошибки доступны через $c->error.

$c->finalize
Завершает запрос.

$c->finalize_body
Завершает тело.

$c->finalize_cookies
Завершает куки.

$c->finalize_error
Завершает ошибки.

$c->finalize_headers
Завершает заголовки

$c->finalize_output
Синоним для finalize_body.

$c->finalize_read
Завершает вход после завершения чтения.

$c->finalize_uploads
Завершает загрузку. Очищает все временные файлы.

$c->get_action( $action, $namespace )
Получает действие в пространстве имен.

$c->get_actions( $action, $namespace )
Получает все действия по имени в текущем пространстве имен и все родительские пространства имен.

$app->handle_request( @arguments )
Вызывается для управления каждым HTTP запросом.

$class->prepare( @arguments )
Создает Catalyst контекст из engine-объявленного запроса (Apache,
CGI, etc.).

$c->prepare_action
Подготавливает действие. См Catalyst::Dispatcher.

$c->prepare_body
Подготавливает тело сообщения.

$c->prepare_body_chunk( $chunk )
Подготавливает кусок данных перед отправкой их HTTP::Body.

См Catalyst::Engine.

$c->prepare_body_parameters
Подготавливает параметры тела.
$c->prepare_connection
Подготавливает соединение.

$c->prepare_cookies
Подготавливает куки гарантирующее что атрибут на объект запроса будет построен.

$c->prepare_headers
Подготавливает заголовок запроса гарантирующее что атрибут на объект запроса будет построен.

$c->prepare_parameters
Подготавливает параметры.
$c->prepare_path
Подготавливает путь и основы.

$c->prepare_query_parameters
Подготавливает параметры запроса.


$c->log_request
Пишет информацию о запросе в логи отладки. Это включает:
метод запроса, путь и удаленный IP.
ключевые слова запроса(см "query_keywords" в Catalyst::Request)
параметры запроса;
файл аплоад.

$c->log_response
Записывает информацию об ответе в логи отладки с помощью вызова
"$c->log_response_status_line" и "$c->log_response_headers".

$c->log_response_status_line($response)
Пишет строку информации об ответе в логи отладки.
Это включает:
статус код ответа;
Content-Type заголовок (если есть)
Content-Length заголовок (если есть)
$c->log_response_headers($headers);
Ловит метод который может быть обернут плагино в лог заголовка ответа. Холостая команда в реализации по умолчанию..

$c->log_request_parameters( query => {}, body => {} )
Логирует параметры запроса в журнал отладки.

$c->log_request_uploads
Логирует отгрузку файла включенный в запрос в лог отладки. Имя параметра, имя файла, тип файла и размер файла включены в режим отладки.
$c->log_request_headers($headers);
Ловит метод который может быть обернут плагино в лог заголовка запроса. Холостая команда в реализации по умолчанию..

$c->log_headers($type => $headers)
Логирует HTTP::Headers (обо запрос и ответ) логи отладки.

$c->prepare_read
Подготавливает входной поток для чтения.

$c->prepare_request
Подготавливает engine запрос.

$c->prepare_uploads
Подготавливает отгрузку.

$c->prepare_write
Подхотавливает выход для записи.

$c->request_class
Возвращает или устанавливает класс запроса. По умолчанию Catalyst::Request.

$c->response_class
Возвращает или устанавливает класс ответа. По умолчанию Catalyst::Response.

$c->read( [$maxlength] )
Читает участок памяти данных из тела запроса. Этот метод предназначен, пока ищется, читается $maxlength байт каждого вызова. $maxlength по умолчанию размер запроса если не объявлен.

Вам нужно установить "MyApp->config(parse_on_demand => 1)" чтобы использовать это напрямую.

Предостережение: Если вы используете read(), Catalyst не обработает тело, так как вам не будет доступен доступ к POST параметрам или файл отправки через $c->request. Вы должны управлять парсингом всего тела самостоятельно.

$c->run
Запускает двигатель.
$c->set_action( $action, $code, $namespace, $attrs )
Устанавливает действие, в данном пространстве имен.

$c->setup_actions($component)
Устанавливает действия для компонентов.

$c->setup_components
Этот метод вызванный изнутри устанавливает компоненты приложения.
Если найдет модули при вызове locate_components method, расширяет их в пакет имен с помощью expand_component_module method, и затем устанавливает каждый компонент в приложение.
"setup_components" опция настройки просматривает оба этих метода.
Установка каждого компонента выполняется с помощью the setup_component method, дальше.

$c->locate_components( $setup_component_config )
Этот метод предоставляет список модулей компонентов, которые вам следует использовать в приложении. По умолчанию используется Module::Pluggable.
Устанавливает "setup_components" опцию настройки, чтобы продйти дополнительные опции прямо в Module::Pluggable. Чтобы добавить дополнительный поиск путей, объявите ключ по имени "search_extra" как массив ссылок. Значения в массиве начинаются с "::" объявит имя класса приложения чтобы вставить их.

$c->expand_component_module( $component, $setup_component_config )
Компоненты найденные с "locate_components" будут переданы в этот метод,
which ожидает возвратить список компонентов (пакет) имен, для установки.

$c->setup_component
$c->setup_dispatcher
Устанавливает диспетчера.

$c->setup_engine
Устанавливает двигатель.
$c->apply_default_middlewares
Добавляет следующий Plack middlewares в ваше приложение, с каких пор они необходимы и для чего нужны:

Plack::Middleware::ReverseProxy, (условно добавляет основанную на статусе $ENV{REMOTE_ADDR}, и может принудить "using_frontend_proxy" или отменить "ignore_frontend_proxy"),
Plack::Middleware::LighttpdScriptNameFix (если вы используете Lighttpd),
Plack::Middleware::IIS6ScriptNameFix (всегда применен это
middleware достаточно гибкая чтобы применить для себя это).
Additionally if we detect we are using Nginx, we add a bit of custom
middleware to solve some problems with the way that server handles
$ENV{PATH_INFO} and $ENV{SCRIPT_NAME}


$c->psgi_app
Возвращает PSGI приложению, код ссылки для catalyst приложения $c. Это голое приложения безо всяких middlewares применений.
"${myapp}.psgi" не берем в расчет.

Это то что нужно, чтобы отыскать PSGI приложение ссылку на код Catalyst приложения для использования в .psgi файлах.

$c->setup_home
Устанавливает домашнюю директорию.
$c->setup_log
Устанавливает лог при реализации Catalyst::Log объекта и прогона его в "log()". Разбирает разделенный запятой список уроавней, чтобы установить их в лог.
Этот метод также устанавливает "debug" метод который возвращает истинное значение в catalyst подкласс если "debug" уровень пройден через список, разделенный запятой, или $CATALYST_DEBUG = 1

Но если лог режим установлен ранее, "setup_log" или вызовом, таким как "__PACKAGE__->log( MyLogger->new
)", то этот метод на самом деле установит лог объект.

$c->setup_plugins
Устанавливает плагины.
$c->setup_stats
Устанавливает класс статистики времени.

$c->registered_plugins
Возвращает отсортированный список плагинов в списке для импорта.
Если дать имя плагина, вернет истину или ложь, если есть такой плагин.
Полностью уточненное имя если имя начинается не с "Catalyst::Plugin::". 

if ($c->registered_plugins('Some::Plugin')) {
...
}

$c->stack
Возвращает ссылку на массив внутреннего стека выполнения (действия который выполняются)

$c->stats
Возвращает текущую временную статистику объект. По умолчанию Catalyst использует Catalyst::Stats, но можно установить другое через stats_class.
Даже если -Stats не активирован, статистика объекта все еще доступна. Включить можно с помощью " $c-"stats->enabled(1) >, это можно использовать для краткого очерка объяснений, хотя MyApp.pm не чего не предоставляет (вроде?)

$c->stats_class
Возвращает или устанавливает статистику (временную статистику) класс. По умолчанию Catalyst::Stats.
$c->use_stats
Возвращает 1 если коллекция статистики доступна.
Примечание, что это метод статистики, не аксессор и следует переопределить с помощью определения "sub use_stats { 1 }" в вашем MyApp.pm, но не вызовом "$c->use_stats(1)".

$c->write( $data )
Пишет $data в выходной поток. Когда используете этот метод напрямую, вам нужно будет вручную установить "Content-Length" заголовок, вашей длины данных если известны.
version
Возращает версию Catalyst. Наиболее полезно дло "powered by" в сообщениях шаблонах системы.


НАСТРОЙКА

Есть несколько базовых 'base' конфигурационных переменных которые могут быть установлены:

· "default_model" - Модель по умолчанию собранная если вы скажите "$c->model".
См "$c->model($name)".

· "default_view" - Вид по умолчанию для генерации
"$c->view" при вызове. См "$c->view($name)".

· "disable_component_resolution_regex_fallback" - Выключает запрет на на разрешение компонента функциональности итак если методы компонента (напр. "$c->controller('Foo')") вызван, тогда рег.выр ищет и если не найдет значение строки и вернет взамен "undef".

· "home" - домашняя папка приложения. В неустановленном приложении это верхний уровень для папок. В установленном приложении это будет директория содержащая "MyApp.pm" .
· "ignore_frontend_proxy" - См "PROXY SUPPORT"

· "name" - имя приложения в сообщениях отладки и отладка и экран приветствия.

· "parse_on_demand" - Тело запроса (например файл загрузки) не будет пройдет пока не будет доступа. Это позволяет вам (для примера) проверить авторизацию( и отвергать загрузку) до действительного получения всех данных. См "ON-DEMAND PARSER"
· "root" - root папка для шаблонов. Обычно это подпапка домашней папки, но вы можете изменить и установить другую директорию для шаблонов.
· "search_extra" - ссылка на массив к Module::Pluggable для дополнительного пространства имен из которых компоненты будут загружены (и созданы и хранятся в "$c->components").

"show_internal_actions" - если истина, значит внутренние действия такие как "_DISPATCH" для показа сообщений в таблицах отладки в тест сервере.

· "use_request_uri_for_path" - контроллирует "REQUEST_URI" или
"PATH_INFO" переменные окружения следует использовать для определения пути запроса.
Наибольшее среда окружения веб-сервера проходит запрошенный путь к приложению использую переменные среды окружения, из которых Catalyst нужно пересобрать базис запроса (т.е. верхний уровениь путь / в приложении доступен как "$c->request->base") и путь запроса ниже этого базиса.

Существует два метода сделать это, оба из которых имеют преимущества и недостатки. Какой метод использовать $c->config(use_request_uri_for_path)" настроить (который можно установить истину или ложь)

use_request_uri_for_path => 0
Это по умолчанию (и) традиционный метод которым Catalyst распознает информацию о пути. Путь генерируется как комбинация "PATH_INFO" и "SCRIPT_NAME" переменных окружения. Позволяет приложению вести себя корректно, когда "mod_rewrite" есть использоваться для переадресации запроса в приложении, как эти переменные подходящие к mod_rewrite чтобы взять счет для редиректа. Хотя у этого метода есть недостаток, он не может декодировать некоторые пути RFC 3875 говорит: "В отличие от URI, PATH_INFO не URL-закодированна, и не может содержать параметры участка пути "Это значит PATH_INFO всегда декодирует, и поэтому Catalyst не может различить / и %2F в пути (в дополнении к другим кодированным элементам).
use_request_uri_for_path => 1
Этот метод использует "REQUEST_URI" и "SCRIPT_NAME" переменные. Как "REQUEST_URI" никогда не кодирует, это значит, что приложения используя этот режим могу правильно управлять URI включая %2F символ (т.е с "AllowEncodedSlashes" включенным "On" в Apache).

Дает что этот метод интепретация пути доказуемо более корректна, рекомедовано что вы используете это если не имеет специальной надобности в деплойменте вашего приложения в не стандартных окружениях, и вы осведомлены в импликации возможности управления кодированием URI путей правильно.
Хотя это также значит что в некоторых случаях когда приложения не установлено прямо в пути, но вместо имеет пути переписанные в него(напр. как .cgi/fcgi в public_html папке, с mod_rewrite в .htaccess файл, или когда SSI используется чтобы переписать страницы в приложении, или когда подпути приложения показываются в других URI чем это которое приложения 'normally' основано с "mod_rewrite"), распознование "$c->request->base" будет неверным.

· "using_frontend_proxy" - См. "PROXY SUPPORT".

ВНУТРЕННИЕ ДЕЙСТВИЯ

Catalyst использует внутренние действия такие как"_DISPATCH", "_BEGIN", "_AUTO", "_ACTION", и "_END". По умолчанию они не показываются в частной таблице действий, но вы можете их увидет с конфигурационным параметром
MyApp->config(show_internal_actions => 1);

ПАРСЕР ПО ТРЕБОВАНИЮ
Тело запроса обычно парситься в начале запроса, но если вы хотите управлять входом самостоятельно, вы можете активировать парсинго по требованию, с помощью
MyApp->config(parse_on_demand => 1);

ПОДДЕРЖКА ПРОКСИ
Многие производства серверов оперируют используя общий двойной сервер подход, с легковесным фронтэндным сервером передает запрос в большой бэкэнд сервер. Приложение запущенное на сервере должно решать две проблемы: удаленный пользователь всегда появляется на 127.0.0.1 и хостнейм сервера предоставляется "localhost" не обращая внимания на виртуальный хост, через который пользователь соединился.
Catalyst автоматически определит эту ситуацию когда вы запустите фро и бэкэнд на одной машине. Следующие изменения создают запрос.

$c->req->address устанавливает реальный IP пользователя, как прочитанный из HTTP X-Forwarded-For заголовка.

Значение хоста для $c->req->base и $c->req->uri устанавливают настоящий хости, как прочитанный из HTTP X-Forwarded-Host заголовка.

В дополнении, вы можете запустить ваше бэкэнди приложения на ненадежном соединении (порт 80) пока ваше фронтэнд прокси запущено под SSL. Если будут расхождения в портах, используйте HTTP заголовок "X-Forwarded-Port" чтобы сказать Catalyst какой порт фронтэнд нужно слушать.
Это позволит все URI создавать должным образом.

В этом случае переход в:

X-Forwarded-Port: 443

Все вызовы к "uri_for" возвратят результат в https ссылку, как ожидалось.

Явно, ваш веб-сервер должен поддерживать эти заголовки чтобы это работало.
В более смешанных серверах средах выполнения где вы можеете иметь свойй фронтэнд прокси сервер(ы) на различных машинах, вам нужно будет установить настройки опции, чтобы сказать Catalyst прочитать проксированные данные из заголовков.
MyApp->config(using_frontend_proxy => 1);

Если вы не хотите использовать поддержку прокси вообще, вы можете установить:
MyApp->config(ignore_frontend_proxy => 0);


Примечание о psgi файлах
Если вы подаете собственные .psgi file, вызывайте
"MyApp->psgi_app(@_);", это не случится автоматически.

Вам таже нужено Plack::Middleware::ReverseProxy в вашем psgi, например:
builder {
   enable "Plack::Middleware::ReverseProxy";
   MyApp->psgi_app
};

Это безоговорочно добавит поддержку ReverseProxy, или если нужно вызовет"$app = MyApp->apply_default_middlewares($app)" (при условии применения поддежки зависимости в вашем конфиге).

См Catalyst::PSGI

БЕЗОПАСНОСТЬ ПОТОКОВ


Catalyst протестирован под Apache 2 в "mpm_worker", "mpm_winnt", автономное вилкоразделение HTTP сервера на Windows. Мы верим что это безопасный для потоков.
Если вы планируете оперировать потоковой средой, помните что все другие модули которые вы используете должны быть также безопасны для потоков. Некоторые модули, особенно DBD::SQLite не безопасны для потоков.
Подписаться на: Сообщения (Atom)