Контент


Ko3: нужны ли нам события (Events)?

Вы наверняка знакомы с библиотекой Event второй ветки Kohana. Также мы помним, что в третьей ветке событий нет (хотя их можно достаточно просто подключить). Как выяснилось, пользователям не нравится такое «обделение», в связи с чем несколько дней назад был создан запрос на dev.kohanaphp.com и началось активное обсуждение.

Если вкратце, то основная проблема при портировании событий — разделение событий на глобальные (т.е. привязанные к объекту Request::instance()) и локальные (события текущего подзапроса). В принципе большинство стандартных событий из Ko2 можно назвать глобальными (инициализация фреймворка, маршрутизация, завершение работы). А для подзапросов наверняка будут пользоваться популярностью события типа «pre_controller» и «render«. Поэтому возникает вопрос, как их разделять между собой.

Вообще идей много. Были высказаны предположения о необходимости «регистрации» подзапросов (т.е. выделения им неких ID) для последующего поиска и связывания, о вложении объекта Event в каждый Request и наоборот — о передаче текущего запроса в конструктор события. Среди прочих предложений мне нравится мысль о выделении двух «направлений» событий — «глобальное» и «подзапрос». Ведь в один момент времени выполняется не более одного подзапроса, так что их можно не разделять. Поэтому вполне симпатично выглядит наличие событий «system.pre_controller» и «system.subrequest.pre_controller«.

Собственно Shadowhand вроде бы и не против включения событий в ядро Ko3, но настаивает о необходимости решения проблемы Events vs HMVC. Так что будем внимательно следить за ходом обсуждения и потирать руки в ожидании такой полезной библиотеки (как по мне, это одна из самых ожидаемых «фич» в Ko3.1.0). А Вам нужны события?

Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

Опубликовано в Kohana3.


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

Будьте в курсе обсуждения, подпишитесь на RSS ленту комментариев к этой записи.

  1. Zares пишет:

    События хороши в плоской структуре MVC.
    В сложной разветвленной, многоуровневой системе — это проблематично, и я думаю — в ближайшее время хорошего решения под HMVC не будет, во всяком случае — до выхода ветки под PHP5.3

  2. BIakaVeron пишет:

    А где на данный момент в Ko3 многоуровневая система? По сути все подзапросы между собой не пересекаются. Поэтому и возникло предложение не разделять между собой подзапросы, а только выделить глобальный Request. Истинной параллельности пока нет ;)

  3. Zares пишет:

    Да… разветвленные многоуровневые системы (веб-приложения) используют HMVC, собственно для решения подобных задач ее и придумали, вот только использование при этом всевозможных фильтров, в том числе и events в том виде, в котором это есть становится проблематичным, поскольку требует наличие некого подобия реестра для основных и дочерних подзапросов, в который можно было бы залить все необходимое — и глобальное, и, соответственно — оперативное локальное.

    Если не брать во внимание KO3, то поиски решений в этом направлении ведутся очень интенсивно, то тут то там появляются первые образцы, под 5.3+ конечно-же ;)

  4. Максим Нагайченко пишет:

    Как-то так получилось, что я с КО2 перепрыгнул на KO3 и на ней остался… Эвенты не юзал, сейчас хватает after and before, так что я буду на нейтрале

  5. BIakaVeron пишет:

    Как только появляется необходимость подключения достаточно большого числа модулей, вспоминаются события. Кроме того, мне очень не хватает стандартного события ‘system.redirect’ в Ko3

  6. Fler пишет:

    @BIakaVeron

    А как события помогаю при подключения большего количества модулей??

  7. BIakaVeron пишет:

    Когда вы производите какое-то действие (опубликование статьи в блоге, написание коммента на форуме, логин/логаут) — все это очень даже может понадобиться подключаемым модулям. Чтобы исключить жесткое связывание между различными элементами системы, напрямую из модуля А вызывать обработчик модуля Б некошерно. А вот сгенерировать событие ‘user.login’ и работать дальше — вот это уже лучше. Модули (теоретически) не знают друг о друге.

  8. Максим Нагайченко пишет:

    > мне очень не хватает стандартного события ’system.redirect’ в Ko3

    а чем тебе не нравится $this->request->redirect или чем оно отличается, от старого.

  9. BIakaVeron пишет:

    В Ko3 $this->request->redirect() тупо бросает header. Бывает, что какие-то модули должны завершить свою работу (например сохранить данные),а в данном случае ничего не получится. Даже метод after() не отработает.
    В 2.3.4 сперва отрабатывало событие ‘system.redirect’, которое позволяло привязать модули к нему и не потерять данные.

  10. Alexander Kupreev пишет:

    Конечно систему событий не так просто совместить с HMVC. Там и там — слабое связывание, но по-разному реализованное. Мне видится только вариант внутри-mvc-шных, локальных событий. Если делать глобальные (на весь глобальный request), то это напрямую нарушает идеологию независимости компонент, тут уже и до реестра недалеко :) Конечно, идеология не самоцель, а средство решения задач. Но из моего скромного опыта красивые способы решения задач обычно идеологически «однородны»

  11. BIakaVeron пишет:

    так компоненты и будут независимы между собой. Их «склеит» объект Event, к событиям которого модули будут привязывать свои методы (хуки). На самом деле ведь модуль !== виджет, так что любой модуль должен иметь возможность участвовать в глобальном развитии реквеста.

  12. Alexander Kupreev пишет:

    то есть «внутримодульные» события будут видны только внутри данного модуля, а глобальные — для всех модулей? Ну, тогда вроде нормально. Хотя остается проблема, например, согласования порядка выполнения модулей, если они изменяют глобальные данные. Или такое не предусматривается, то есть читать можно, а писать — нет?

  13. BIakaVeron пишет:

    Скажем так — привязка модуля А к событиям модуля Б маловероятна (модули обычно не зависят друг от друга). Исключение — основные модули проекта (модули ядра).

    Обычно порядок неважен, т.к. модули берут данные на чтение (событие выступает как «осведомитель»), либо дополняют Event::$data своими параметрами (в этом случае обычно она не пересекается, т.к. модули управляют каждый своими данными).

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

  14. Fler пишет:

    А поддержка событий не будет тормозить ядро фреймворка?
    Вроде от событий и отказались в силу производительности.

  15. BIakaVeron пишет:

    Естественно, без событий работать будет быстрее :) Как и без ORM/QBuilder и прочих удобных библиотек. По идее можно где-то в настройках фреймворка добавить параметр use_events, чтобы отключать события при необходимости. Вопрос только, насколько это будет удобно и практично.

  16. Fler пишет:

    @BIakaVeron
    Спасибо. Просто ORM и т.д, это же отдельные модули. А тут, как я понимаю, события в ядро хотят воткнуть.

  17. BIakaVeron пишет:

    Такие модули, как ORM и Image, являются самодостаточными. А вот события помимо чисто пользовательских (т.е. инициируемых пользовательскими классами, обычно контроллерами) должны генерировать системные, чтобы иметь больший контроль над ходом обработки запроса. Тут (ИМХО) одним файлом bootstrap.php не обойтись…

  18. Zares пишет:

    Проходил мимо, дай думаю — загляну…

    Обсуждение, так сказать, состоялось, но многие-ли имели при этом представление о чем идет речь… :?

    Я порекомендовал-бы взглянуть на один из простейших, но достаточно иллюстративный пример работы evets, чтобы все-таки понять кому и зачем они нужны:
    http://github.com/Zeelot/event

  19. BIakaVeron пишет:

    @Zares
    Для полноты картины надо еще, чтобы метод two() находился в совершенно другом модуле/плагине и подключался оттуда же. Так можно продемонстрировать возможность обмена данными между модулями без непосредственного связывания их между собой. Данный пример собственно показывает работу измененного (по сравнению с Ko2.x) класса Event, в котором возможны вложенные события без потери данных.

  20. Zares пишет:

    ***Для полноты картины надо еще, чтобы метод two() находился в совершенно другом модуле/плагине и подключался оттуда же…***
    …Или на удаленном сервере в распределенной системе ;)



Можно включить подсветку кода: <code><pre lang="">...</pre></code>
Разрешены некоторые HTML теги

или используйте trackback.