Вы навесили 'on EVENT_PAGE_REQUEST' к объекту приложения Yii::$app, а trigger вызываете в объекте контроллера $this. Поэтому ничего не происходит. Но, первым делом, можно порассуждать, куда мы можем события поместить и откуда дергать.
Всё зависит от того, что Вы хотите отслеживать: запрос к приложению, запрос к модулю или запрос к контроллеру.
Так, в зависимости от ситуации, можно напридумывать кучу способов:
Либо оставить своё событие:
Код: Выделить всё
'on pageRequest' => ['common\modules\partnership\common\models\TrafficLog', 'countRequestPage'],
но генерировать его для самого Yii::$app:
Код: Выделить всё
Yii::$app->trigger(self::EVENT_PAGE_REQUEST);
Либо перенести событие в модуль и в init() самого модуля цепляться на $this->on(...), вызывая из BaseController метод модуля:
Либо оставить код в контроллере как есть, но навеситься глобально:
Код: Выделить всё
Event::on(BaseController::EVENT_PAGE_REQUEST, ['...']);
Но всё это - костыли и компромиссы. Первый не соответствует простейшей логике использования всего по назначению и привносит обратную лишнюю зависимость модуля от приложения. Второй - верный, но его можно упростить, отказавшись от собственного события. Но всё равно к задаче глобального трекинга он не подходит. Третий лёгок, но не слишком явен и сильно мешает тестированию, так как это глобальный синглтон, умеющий только накапливать обработчики.
Как сделать это более-менее явно?
В системе уже есть события, генерируемые разным объектами (приложением, модулями, контроллерами и прочими). Добавлять события в другие объекты мы не должны (за исключением работы через общую шину событий, но это не наш случай), и от этого они там выполняться не начнут. Поэтому логичный вариант - подписаться на события объекта, который их сам генерирует.
Если нужно отловить вообще каждый запрос отовсюду, то навесьтесь на встроенное событие EVENT_BEFORE_REQUEST (или EVENT_AFTER_REQUEST) либо EVENT_BEFORE_ACTION (или EVENT_AFTER_ACTION) самого приложения в конфиге:
Код: Выделить всё
[
'on beforeRequest' => ['common\modules\partnership\common\models\TrafficLog', 'countRequestPage'],
]
В других случаях помещение своих собственных событий в Yii::$app засоряет этот объект приложения (используя его ещё и как общую глобальную шину). Незачем в объект класть то, чего у него нет и подо что он не приспособлен.
Либо, если нужно отслеживать переходы только в модуле, навесьтесь аналогично на EVENT_BEFORE_ACTION или EVENT_AFTER_ACTION самого модуля в его методе init() для своих обработчиков:
Код: Выделить всё
class MyModule extends Module
{
public function init() {
parent::init();
$this->on(self::EVENT_BEFORE_ACTION, [$this, 'countRequestPage']);
}
public function countRequestPage(Event $event) {
...
}
}
или в конфиге для чужих:
Код: Выделить всё
[
'modules' => [
'my-module' => [
'class' => '...',
'on beforeRequest' => ['...\OrherTrafficLog', 'countRequest'],
].
]
Оба варианта позволяют легко избавиться от такого BaseController вообще.
Если же событие возникает только в одном контроллере (а не в базовом BaseController, от которого у Вас наследуются другие), то поместите его именно в этот контроллер. Но такое редко бывает нужно, так как нормальный контроллер - это расходный материал, никакой собственной логики не имеющий.
В любом случае следуйте здравому смыслу. У объекта могут быть его встроенные свойства (имя, цвет), его методы (открыть, закрыть), его события Events (проголодался, завял) и, возможно, его исключения Exception (не доел). Всё скомпоновано внутри объекта и живёт своей жизнью. Он нам сам говорит методом trigger(), что он завял или проголодался, а не мы ему так сделать приказываем. И только внешний код уже устанавливает его свойства, вызывает его методы и подписывается через on() на его внутренние события.
Так что стремитесь, чтобы события лежали в самих объектах, чтобы метод trigger() вызывался только внутри объекта им самим (представьте, что он protected, а не public) и чтобы любое навешивание чего-то на объект происходило только снаружи.
Так что события (Events) и исключения (Exceptions) (как и просто свойства и методы) полезны для односторонней коммуникации внешних систем с внутренними. А неконтролируемая встречная связка одноуровневых объектов напрямую друг с другом (через тот же Event::on()) без парящего над этим всем дирижёра нередко приводит к хаосу циклических зависимостей.