Zend_Controller_Action - абстрактный класс, который можно использовать для реализации контроллеров действий для последующего их использования с фронт-контроллером при разработке сайта, основанного на паттерне Model-View-Controller (MVC).

Для того, чтобы использовать Zend_Controller_Action, нужно создать его подкласс в своей действующей директории контроллеров (или расширить его для создания своего базового класса контроллеров действий). Работа с ним в основном сводится к созданию его подкласса и написании методов действий, соответствующих различным действиям, которые должен обрабатывать этот контроллер. Маршрутизатор и диспетчер компоненты Zend_Controller будут считать за методы действий все методы в классе контроллера с именем, заканчивающимся на 'Action'.

Для примера предположим, что ваш класс определен следующим образом:

class FooController extends Zend_Controller_Action
{
    public function barAction()
    {
        // делает что-нибудь
    }

    public function bazAction()
    {
        // делает что-нибудь
    }
}

Приведенный выше класс FooController (контроллер foo) определяет два действия - bar и baz.

Класс может быть дополнен инициализирующим методом, методом действия по умолчанию (если не был вызван метод, либо вызван несуществующий метод), перехватчиками pre- и post-dispatch и различными вспомогательными методами. Этот раздел служит обзором функционала контроллера действий.

Поведение по умолчанию

По умолчанию фронт-контроллер активирует помощника действий ViewRenderer. Этот помощник обеспечивает добавление объекта вида в контроллер и автоматический рендеринг видов. Вы можете отключить его в своем контроллере действия, используя один из следующих методов: class FooController extends Zend_Controller_Action {     public function init()     {         // Локально, только для данного контроллера:         $this->_invokeArgs['noViewRenderer'] = true;         // Глобально:         $this->_helper->removeHelper('viewRenderer');         // Тоже глобально, но должен использоваться вместе         // с локальной версией для того, чтобы распространить         // действие на данный контроллер:         Zend_Controller_Front::getInstance()             ->setParam('noViewRenderer', true);     } } initView(), getViewScript(), render() и renderScript() служат посредниками для ViewRenderer, пока этот помощник находится в брокере помощников и не установлен флаг noViewRenderer. Вы можете также отключить рендеринг для отдельного вида посредством установки флага noRender в ViewRenderer: class FooController extends Zend_Controller_Action {     public function barAction()     {         // отключение авторендеринга для этого действия:         $this->_helper->viewRenderer->setNoRender();     } } Основные причины для отключения ViewRenderer - вам просто не нужен объект вида или если вы не производите рендеринг через скрипты вида (например, когда используется контроллер действий для обслуживания протоколов веб-сервисов, таких, как SOAP, XML-RPC, или REST). В большинстве случаев не нужно будет глобально отключать ViewRenderer, только избирательно в отдельных контроллерах или действиях.

Несмотря на то, что вы всегда можете переопределить конструктор контроллера действий, мы не рекомендуем делать это. Zend_Controller_Action::__construct() выполняет некоторые важные задачи, такие, как регистрация объектов запроса и ответа, аргументов вызова, переданных из фронт-контроллера. Если необходимо переопределить контроллер, то всегда вызывайте конструктор родительского класса parent::__construct($request, $response, $invokeArgs) в конструкторе подкласса.

Более подходящим способом настройки инстанцирования является использование метода init(), который вызывается в конце выполнения __construct(). Например, если вы хотите устанавливать соединение с БД при инстанцировании:

class FooController extends Zend_Controller_Action
{
    public function init()
    {
        $this->db = Zend_Db::factory('Pdo_Mysql', array(
            'host'     => 'myhost',
            'username' => 'user',
            'password' => 'XXXXXXX',
            'dbname'   => 'website'
        ));
    }
}

Zend_Controller_Action определяет два метода, которые вызываются до и после требуемого действия, preDispatch() и postDispatch(). Они могут быть полезны в различных случаях - например, проверка аутентификации и списка управления доступом до запуска действия (при вызове метода _forward() в preDispatch() текущее действие будет пропущено) или размещение сгенерированного содержимого в шаблоне боковой части сайта (метод postDispatch()).

С объектом контроллера регистрируется несколько объектов и переменных, они имеют свои методы-аксессоры.

	По умолчанию интеграция вида производится через ViewRenderer
	Изложенное в этом разделе действительно только в том случае, если вы явным образом отключили ViewRenderer. Иначе вы можете спокойно пропустить этот раздел.

Zend_Controller_Action предоставляет простейший и гибкий механизм интеграции видов. Два метода осуществляют это: initView() и render(). Первый метод выполняет отложенную загрузку открытого свойства $view, второй выполняет рендеринг вида, основываясь на запрошенном в данный момент действии, используя иерархию директорий для определения пути к скрипту.

applicationOrModule/
    controllers/
        IndexController.php
    views/
        scripts/
            index/
                index.phtml
        helpers/
        filters/

24.7.5.2. Рендеринг видов

render() имеет следующую сигнатуру:

string render(string $action = null,
              string $name = null,
              bool $noController = false);

render() рендерит скрипт вида. Если не были переданы аргументы, то предполагается, что запрашивается скрипт [controller]/[action].phtml (где .phtml - значение свойства $viewSuffix). Передача значения для $action вызовет генерацию этого шаблона в поддиректории [controller]. Для того, чтобы отменить использование поддиректории [controller], передавайте значение true для $noController. Шаблоны рендерятся в объект ответа, если же вы хотите сохранить результат в именованный сегмент объекта ответа, то передавайте значение для $name.

Замечание

Поскольку имена контроллера и действия могут содержать символы-ограничители слов, такие, как '_', '.', и '-', то render() нормализует их к '-', когда определяет имя скрипта. Внутри себя для такой нормализации он использует ограничители слов и путей для диспетчера. Таким образом, запрос к /foo.bar/baz-bat приведет к рендерингу скрипта foo-bar/baz-bat.phtml. Если ваш метод действия содержит camelCase, то следует иметь в виду, что при определении имени скрипта вида результатом будут разделенные '-' слова.

Некоторые примеры:

class MyController extends Zend_Controller_Action
{
    public function fooAction()
    {
        // Рендеринг my/foo.phtml
        $this->render();

        // Рендеринг my/bar.phtml
        $this->render('bar');

        // Рендеринг baz.phtml
        $this->render('baz', null, true);

        // Рендеринг my/login.phtml в сегмент 'form' объекта ответа
        $this->render('login', 'form');

        // Рендеринг site.phtml в сегмент 'page' объекта ответа,
        // при этом не используется поддиректория 'my/'
        $this->render('site', 'page', true);
    }

    public function bazBatAction()
    {
        // Рендеринг my/baz-bat.phtml
        $this->render();
    }
}

Кроме аксессоров и методов интеграции видов, Zend_Controller_Action имеет несколько сервисных методов для выполнения распространенных зачач в методах действий (или в методах pre- и post-dispatch).

Задумано, что в порядке создания контроллеров действий должны создаваться подклассы от Zend_Controller_Action. Как минимум, вам нужно будет определить методы действий, которые может вызывать контроллер.

Помимо создания полезного функционала для своих веб-приложений, вы можете также обнаружить, что большинство установок или сервисных методов повторяются в ваших различных контроллерах. В этом случае создание общего базового контроллера, расширяющего Zend_Controller_Action, может решить проблему избыточности.

class MyController extends Zend_Controller_Action
{
    public function __call($method, $args)
    {
        if ('Action' == substr($method, -6)) {
            // Если метод действия не найден, то рендерится шаблон ошибки
            return $this->render('error');
        }

        // все другие методы бросают исключение
        throw new Exception('Invalid method "'
                            . $method
                            . '" called',
                            500);
    }
}

class MyController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->render();
    }

    public function __call($method, $args)
    {
        if ('Action' == substr($method, -6)) {
            // Если метод действия не был найден, то производится
            // переход к действию index
            return $this->_forward('index');
        }

        // все другие методы бросают исключение
        throw new Exception('Invalid method "'
                            . $method
                            . '" called',
                            500);
    }
}

Как и метод __call(), любые аксессоры, сервисные методы, методы инициализации, вида и перехвата, упомянутые ранее в этом разделе, могут быть переопределены для того, чтобы приспособить свои контроллеры под конкретные нужды. Например, если вы храните свои объекты вида в реестре, то можете модифицировать свой метод initView():

abstract class My_Base_Controller extends Zend_Controller_Action
{
    public function initView()
    {
        if (null === $this->view) {
            if (Zend_Registry::isRegistered('view')) {
                $this->view = Zend_Registry::get('view');
            } else {
                $this->view = new Zend_View();
                $this->view->setBasePath(dirname(__FILE__) . '/../views');
            }
        }

        return $this->view;
    }
}

Надеемся, из написанного в этом разделе вы смогли увидеть, насколько гибка эта компонента, и как можно заточить ее под нужды своего приложения или сайта.