Содержание


Примеры


Examples, примеры, MVC, ЗФ2, Zend Framework 2, ZF2, ру, ru






Контроллеры

 

Доступ к Запросам (Request) и Ответам (Response)

 

При использовании AbstractActionController или AbstractRestfulController, объекты запроса и ответа внедряются в контроллер сразу после отработки метода «dispatch()». Получить к ним доступ можно следующими способами:

// Using explicit accessor methods
$request  = $this->getRequest();
$response = $this->getResponse();
 
// Using direct property access
$request  = $this->request;
$response = $this->response;

Также, если Ваш контроллер реализует InjectApplicationEventInterface ( как AbstractActionController и AbstractRestfulController), Вы можете получить доступ к этим объектам через MvcEvent:

$event    = $this->getEvent();
$request  = $event->getRequest();
$response = $event->getResponse();

Выше описанный способ может быть полезен при создании слушателей контроллера.

 

Доступ к параметрам маршрутизации

 

Параметры возвращаются, когда процесс маршрутизации завершается и находится в Zend\Mvc\Router\RouteMatch. Если Ваш контроллер реализует InjectApplicationEventInterface (как AbstractActionController и AbstractRestfulController), то получить доступ к объекту можно через MvcEvent:

$event   = $this->getEvent();
$matches = $event->getRouteMatch();

Как только Вы получили объект RouteMatch, появляется возможность извлекать необходимые параметры.

 

Ранний возврат

 

Вы можете эффективно использовать короткие замыкания в приложении путем возврата ответа от контроллера или события. При обнаружении такого замыкания, останавливается выполнение менеджера событий и возвращается к экземпляру «Application».

 

Пример: Плагин Redirect возвращает ответ, который сразу же может быть возвращен, что б выполнить запрос как можно быстрей. В других случаях такой подход можно применять для возврата данных в формате JSON или XML от веб – сервисов, возврата «401 Forbidden» и т.д.

 

Начальная загрузка (Bootstrapping)



 

Регистрация слушателей модуля

 

Часто возникает необходимость создания слушателя для модуля. Например: авторизация, логин, кэширование и многое другое.

 

В каждом классе «Module» может быть метод «onBootstrap()». Как правило настройка модуля и создание слушателей событий происходит в этом методе. Этот метод вызывается в каждом модуле при каждой загрузке приложения, поэтому должен использоваться исключительно для «легковесных задач».

 

Базовый класс Application, который идет с фреймворком имеет в своем составе EventManager связанный  с ним, и как только модули инициализируются, срабатывает события «bootstrap», которые вызывают метод «getApplication()».

 

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

namespace SomeCustomModule;
 
class Module
{
    public function onBootstrap($e)
    {
        $application = $e->getApplication();
        $config      = $application->getConfiguration();
        $view        = $application->getServiceManager()->get('View');
        $view->headTitle($config['view']['base_title']);
 
        $listeners   = new Listeners\ViewListener();
        $listeners->setView($view);
        $application->getEventManager()->attachAggregate($listeners);
    }
}

В данном примере были продемонстрированы несколько вещей.

Первое -  это слушатель на событие «bootstrap»  приложения ( метод «onBootstrap()»).

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

 


Автор статьи: DuB