Мысли по поводу структуры и функциональности модуля

[biakaveron]

В принципе, класс Event из второй версии Kohana полностью устраивает, за исключением одного главного недостатка - он не учитывает наличие HMVC, который появился в третьей.

Необходимо отделять события/колбэки для различных запросов (requests). Кроме того, рассмотреть возможность параллельного существования глобальных и локальных событий. Локальные применяются только в рамках текущего запроса, а глобальные - для каждого.

[aktuba]

Я, все-таки, считаю что разделение на локальны/глобальные - не нужны. Надо просто в событии передавать объект Request и обработчик сам должен решать, как поступать. В такой реализации, в рамках одного обработчика можно реализовывать разную логику, вместо того, чтобы плодить кучу разных обработчиков под похожие события.

[Fedott]

Мне тоже кажется что нужно просто передавать событию объект запроса, и пусть обработчик сам решает как поступить. Так мне кажется будет проще и гибче.

[biakaveron]

Просто я не вижу смысла передавать request, если в большинстве случаев нужен просто текущий. Глобальные для того и нужны, чтобы вместо Request::initial() передавать, скажем, TRUE.

[aktuba]

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

Может я чего-то не понимаю... Назови, plz, моменты, когда передача Request - плохо?

[biakaveron]

Ну давай просто сравним:

Event::add('custom.bar', array($this, 'b'), Request::initial()); // глобальный обработчик

и

Event::add('custom.bar', array($this, 'b'), TRUE); // глобальный обработчик

Как минимум читается легче. Зачем передавать лишние объекты, когда это можно спрятать внутри модуля?

[aktuba]

А как в твоем случае передать не глобальный Request, а дополнительный? Чтобы событие срабатывало только в нем?

Еще вопрос: что нужно чаще, глобальные обработчики или локальные? Определяемся и делаем короткую запись:

Event::add('custom.bar', array($this, 'b'));

В других случаях нет разницы, Request::initial() или TRUE/FALSE.

[biakaveron]

ИМХО, должно быть 2 возможности - привязаться к текущему запросу (по умолчанию), либо к глобальному. Думаю, в большинстве случаев нужен будет текущий, поэтому для него я и предлагаю передавать булевый флаг в качестве третьего параметра. В остальных случаях просто используем короткую запись с двумя аргументами, все верно.

[aktuba]

Погоди... По твоему, событие на сторонний Request не нужен? Например, я делаю запрос к стороннему API (или даже внутреннему) и создаю событие, которое должно работать только в пределах этого запроса. Ни локальный, ни глобальный обработчик тут не подходит, верно?

[biakaveron]

А смысл? Почему не использовать локальное событие? Все равно ты где-то обрабатываешь ответы от этих сторонних (и не очень) API.

[aktuba]

Что значит "локальное событие"? Если использовать локальный обработчик, то он будет срабатывать только в initial-апросе, верно? Если-же глобальный, то во всех без исключения. Как мне, в твоем варианте, запускать обработчик только во внутренних запросах или в сторонних?

[biakaveron]

Вообще-то я имел виду локальный - это текущий запрос (Request::current()), а глобальный - Request::initial().

[aktuba]

Ну тогда проще в класс добавить врапперов: add_local и add_global, которые проставят нужные параметры. В любом случае, даже если идти по твоей схеме, TRUE/FALSE быть не должно. Либо Request, либо Event::LOCAL/Event::GLOBAL. Я за Request.

Кроме того, хотелось бы иметь возможность включать/выключать события в коде (Event::on/Event::off). Тут константы будут, конечно-же, удобнее, чем объекты Request, но это не сильно принципиально.

В крайнем случае, можно заложить и TRUE/FALSE, и Request и конвертировать при создании ;)

[biakaveron]

Можно и врапперы, не суть. Внутренности все равно будут одни и те же. Но смысла в передаче конкретного запроса я не вижу. Как минимум потому, что выглядит все это неопрятно. Тогда уж лучше add() и add_global().

Не совсем понял насчет отключения событий. Почему нельзя такой вариант в хэндлере предусмотреть? Я еще понимаю выделить только глобальные события (то есть которые не будут обрабатываться внутри подзапросов)...

[aktuba]

Вообще, это только пожелание. Бывают ситуации, когда при определенных обстоятельствах обработчик какого-то события не должен сработать. Например:

public function action_index()
{
try {
...
} catch(Exception $e) {
Event::off('logger');
}
}

public function after()
{
Event::run('logger');
}

Понятно, что можно сделать следующим образом:

private $off_logger = FALSE;

public function action_index()
{
try {
...
} catch(Exception $e) {
$this->off_logger = TRUE;
}
}

public function after()
{
if (!$this->off_logger)
{
Event::run('logger');
}
}

но согласись, первый вариант красивее.