Контексты и приоритеты | Зона разработки

В этой версии добавлена полноценная поддержка контекстов, в том числе и «mgr». Кроме того, теперь для обработчиков событий можно указать порядок загрузки. Теперь подробнее.

Контексты

Те, кто просмотрел скринкасты создания данного компонента, должны помнить, что при создании классов посредников и обработчиков событий мы добавили свойство contexts, представляющее собой массив контекстов, в которых они будут действовать. Свойство-то добавили, но реализацию оставили на будущее. И вот пришло время закрыть этот должок. Теперь вы также легко можете работать с любыми событиями админки. Просто создавайте методы OnDocFormSave, OnBeforeManagerPageInit или OnSiteRefresh и т.д.

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

Надо разобраться!

Хочу обратить внимание на один момент при работе с фронтэндом. Тот посредник, в котором переключается контекст будет всегда проверяться в контексте web. Т.е. если вы для этого посредника укажите контекст, отличный от web, посредник никогда не сработает. Происходит это потому, что проверка текущего контекста и контекстов, указанных в посреднике, происходит перед его запуском. А в этот момент контекст ещё не переключен (т.е. ещё web). Таким образом, в этом посреднике можно указывать только 2 контекста — web и mgr.

Решается это созданием отдельного посредника для переключения контекста. Он должен выполняться первым. Следующие посредники будут выполняться уже в нужном контексте и сравнение будет корректным.

При установке компонента создаётся один файл посредника (core/middlewares/init.php) и файл обработчика событий (core/listeners/test.php). Причем посредник уже подключен — указан в системной настройке. Т.е. можно сразу с ним работать. Обработчик нужно подключить самостоятельно. Это можно сделать как в админке, так и в посреднике. Пример подключения в посреднике:

public $contexts = ['web', 'mgr'];

public function onRequest()
{
    // Переопределить заново список обработчиков
    config(['middlewares_listeners' => 'test']);
    // Добавить в конец списка к уже имеющимся
    config(['middlewares_listeners' => config('middlewares_listeners') . ',test']);
}

С динамическим подключением посредников логика немного другая. Их придётся запускать самостоятельно.

// 1. Загрузить класс
$class = app('MiddlewareService')->loadMiddlewareClass('myMiddleware');
// 2. Выполнить нужный метод
(new $class($this->modx))->onRequest();

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

Приоритеты обработчиков событий

При инициализации MODX формирует карту событий и в ней определяет какие плагины должны сработать и для каких событий. Обработчики подключаются уже к готовой карте — дописываются в конец списка плагинов для каждого события. В этой версии появилась возможность подключить обработчик в начало списка плагинов, чтобы они выполнились до них. Чтобы сделать это, нужно в соответствующем методе указать параметр before с дефолтным значением true.

public function OnHandleRequest($before=true) 
{
    //
}
    
public function OnBeforeDocFormSave($properties, $before=true) 
{
    extract($properties);
    if (empty($resource->longtitle)) {
        $this->modx->event->output('Заполните расширенные заголовок!'); // Вывод ошибки в модальном окне
    }
}

Заключение

Разработка данного компонента полностью закончена. Всё запланированное реализовано. В ближайшее время выложу скринкаст, в котором мы наглядно пробежимся по данным фичам. Так что загляните сюда через пару дней.

Update 28.11.2017

Комментарии ()

Вы должны авторизоваться, чтобы оставлять комментарии.