p.s. MVC но не совсем звучит как-то по джуниорски

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

В статье приведены базовые события, на самом же деле по мере уточнения логики модулей (движок то ещё делается) у них появляются более специфичные события. В данной системе нет стремления к аспектному программированию, когда реально нужно было бы вызывать события после каждого оператора или в лучшем случаи вначале и в конце тела каждой функции/метода. На такую мысль может навести событие AFTER в модуле Request. Его уже нет Дело в том, что вызов события предполагает какой-то вид действия, тем самым указывая направление расширения функционала, а не просто выполнения чего-то, чего угодно только от того что тот модуль сработал. Здесь пока логика контролируется в основном стремлением культурно программировать, процесс движется и к его финалу сформируется некое правило по событиям.

Но главное внимание нужно обращать совсем на другое! Посмотри, как вызываются события – просто указывается строкой название, а это даёт возможность, исходя из любых условий, формировать событие динамически. А теперь рассмотрим, где это применяется.

Работу системы необходимо рассматривать глобально. Есть клиент, есть сервер, на сервере наша система обрабатывающая запросы клиента. Учитывается, что запросы могут быть в разных форматах, это может быть в большинстве случаев обычный HTTP, а далее на его основе и JSON, и XML-RPС, REST, да даже чуть на забыл непосредственное обращение к фалам. В данной статье эта возможность обозначена модулями Page, X, FILE как пример. Так вот, представим работу модуля XML-RPС.

Он разбирает полученный xml и должен вызвать соответствующее действие в системе. Именно здесь события выдают максимальную гибкость. Так модулю XML-RPС достаточно вызвать событие с динамически сформированным именем (имя может быть указано в запросе) и всё. Далее уже какой модуль зарегился на такое событие, тот и будет выполнять действие. При подключении нового модуля не нужно модернизировать все модули обрабатывающие запросы, дополнять их алгоритм, их API.

Предположим, есть модуль который работает с файлами, он генерирует событие:
READFILE. Появилась необходимость добавить модуль какой-то проверки до чтения файлов — пусть это будет модуль CheckBefore. Я ввожу этот модуль в систему просто регаясь на событие READFILE. Но что я должен знать: В каком именно месте кода другого модуля это событие — сгенерено ДО чтения файла, а не в МОМЕНТ или ПОСЛЕ, это очень важно — иначе технически мой новый модуль становится не удел. Хорошо, а допустим мне завтра нужно внести какую-то пост-обработку файла что тогда? Я должен ожидать что в системе существует
событие READFILE_END? И уже на него регистрироваться? Пока я вижу что события представляют собой высокоуровневые абстрактные события быстро исчерпывающие свой потенциал по гибкому наращиванию системы.

Я склонен полагать, что чтобы завтра прикрутить модуль который не был необходим вчера, не найдется заранее подготовленного события, и тогда мы руками лезем в код тех модулей события которых нам нужны — гибкость ли это и расшираяемость? Чтобы система была гибко расширяема практически без вылазок в код других модулей, технически, надо чтобы почти после каждых значимых строк кода всех модулей были генерации событий, потому что только в эти места можно будет потом вклинить вызовы. Мне кажется, что выглядит не очень гибко и не очень лаконично. Не проще ли было следовать тому, что и так уже придумано, вводить модули ни как орбитальные станции, а как подключаемые и наследуемые библиотеки — то есть каждый функционал системы это вызов функции — который дробится на более простые функции, а они в свою очередь на еще более простые, таким образом перекрывая или дополняя, мы всегда можем внести коррективы практически в любой участок системы — а технически это разделено отдельными папками и файлами — как модули в питоне. И ненужно достигать этого неродной для PHP-интерпретатора событийной моделью и в идеале испещрять каждые две строчки кода генерацией события, в стиле READFILE_BEFORE, READFILE_NOW, READFILE_AFTER, и т.п.

Да и вообще зачем внутри системы такое жесткое API? При взаимодействии со сторонними ПО? — но это другое дело и другая история. Сегодня приступаю к детальному чтению следующих глав по архитектуре данных. Вообще у меня закрадываются подозрения что автор смотрит дальше и хочет привести не только данные к общей гомогенной среде но и функционал по возможности — этим возможно и продиктованы введенные Events и Actions. Я тоже думаю, что на самом программа — есть какой-то частный случай общего хранилища данных, то есть инфморционное сетевое хранилище не только статично и имеет связи, но еще и активно и производит действия по управлению какой-то части информации. Эту точку зрения я слышал у г-на Нариньяни — директора РосНИИ ИИ. И с ней согласен, но мало пока представляю с какого бока к этому подобраться.

P.S.: На самом деле мне жутко интересно обсуждать все теоритические и практические моменты, до которых у меня, я надеюсь, хватает ума. Я ЗА эту CMS-ку потому что её концепция в любом случае ближе всех мне по духу. Вчера очередной раз почитал про DJANGO — ну не нравится мне их ORM — ну что тут поделаешь, ну слишком они ложатся по фактическую архитектуру рели в угоду производительности и слабо мне кажется думали о теоритической модели информационного пространства, более близкого по признакам к реальности.

А что в ином случае системе надо догадываться что к ней прикрутили?
ИМХО функционал расширяется путем расширения самих функций и методов изнутри, и ненадо системе знать.
Вчера функция была такой:
File.Read(
File.open()
File.readline()
)

Завтра прикрутили штуку File.check()

Теперь это
File.Read(
File.check()
File.open()
File.readline()
)

Все, кто вызывал File.Read() будут по-прежнему его вызывать
не зная что функционал обогател.

Я не рассматриваю модульность (новости, и прочее) я понимаю что модули тут есть аспектные компоненты.

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

Конечно, я согласен с тем, что если всю логику системы пересвязать событиями, то получится не то что коллизия… Не пойму только, почему вы события сравниваете с GOTO, ведь неслабую запутанность можно реализовать и прямым вызовом функций, которые вызывают другие, а следующие ещё каике-то, а потом зацикливание, рекурсия…

Нужно понимать, что в данной системе модули не есть некий набор подобного функционала, как в существующих движках, типа модуль каталога и новостной ленты принципиально ничем не отличаются. В этой CMS каждый модуль это уникальное звено и связывание этих звеньев, я бы даже сказал, самоконтролируется общей логикой. В общем плане прорисовывается иерархическая последовательность и только в исключительных ситуация эта иерархия нарушается, например при возникновении системной ошибки прекращается общий ход исполнения и от модуля Errors обработкой его события отправляется ответ клиенту. Не нужно полагать, что раз событие, то оно будет обрабатывать всеми подряд, во всяком случаи модули будут разрабатывать не идиоты, да и если я пишу модуль расширяющий что-то, то зацикливание могу осуществить, если напрямую вызову функции, которые расширяю (может не явно их), поэтому это должно по любому контролироваться, так как это сознательное создание цикла или рекурсии. Тут ты можешь зацепиться за мелкие детали и продолжить спор )

С общими данными запроса всё просто. Запрос – это фактически вызов одного действия и указание в юрле, что требуется клиенту в ответ получить. Так вот, фактически с данными запроса не будут работать все модули подряд. В обще, в данный момент серьезно прорабатываются понятие действия в движке (до этого всё время было уделено модулю данных). Так вот, о чём это я – о том, что возможно данные $_POST будут просто являться параметрами действия и не будут оставаться в модуле Request в «контейнере данных», а этот контейнер будет передаваться действию.

Так что в этой архитектуре, я боюсь, один из философов Дейкстры рискует остаться без обеда — потому всегда все вилки будут заняты по разным причинам

$n = 4 # состояние системы перед
$i = 2 # моментом исполнения кода ниже
…

FirstMethod{ # некий код некое место которое сейчас выполняется
if $n>0 and $i>0 {
EventSend(calc) # сгенерилось событие — «мы готовы считать»,
# ничего не зная кто и как его обрабатывает в уже данный момент

$n / $i # ожидали деления 4/2, а получили 0/2 и Error dev 0,
# этот участок кода был к этому не готов к этому, потому что не знал КАК и КТО
# обрабатывает это событие
}

}

EventSend{ # Событийный движок — делает свое «грязное» дело
# вызывает ежемоментно методы зареганые на событие
if calc{
SecondMethod() # просили — получайте
}
}

SecondMethod{
$n = 0 # Допустим этот метод обычно всегда сбрасывает
# в нулевое значение переменную $n
# но тогда этот метод работая с $n должен 100% знать КТО, КОГДА,
# и при КАКИХ обстоятельствах работает с $n, чтобы не допустить ошибки
# по возвращению из обработчика событий
# То есть один метод должен знать обо всех методах
# которые так или иначе затрагивают общие данные — а общие данные всегда будут
# и аутентификации и контент, и состояния и пр.

}