Я пытаюсь определить некоторые из плюсов и минусов наличия CMS, который управляется событиями.
Событие нередко. Вы видите это на многих языках сценариев, таких как Actionscript, javascript, jquery, которые связаны с клиентом. Как насчет в CMS, где события и их ответы происходят на сервере. Какие преимущества или недостатки может иметь этот подход, и какие другие подходы существуют, что люди могут предпочесть больше.
PS Обратите внимание, что я использую ActionScript, JQ и JS только в качестве примера. Вы понимаете, что когда речь идет о CMS таким образом, события и их ответы – все серверные вещи.
Редактировать : Я вижу, что многие люди говорят, что нет смысла использовать управляемые событиями, поскольку они не понимают, что это такое. Одна из систем CMS, которые уже используют этот подход, – это Drupal, поэтому поверьте мне, что это уже существующий способ, я не вытаскиваю идеи из своего A. Это просто означает «внутренности» CMS (все серверные вещи) управляются событиями. Ядро делает свою вещь AND определяет события. Плагины могут реагировать на эти события, чтобы добавить свою собственную логику. Я упоминаю ActionScript как пример, потому что на стороне клиента это понятие наиболее известно, но оно также может быть на стороне сервера, возможно, не так важно для обычных приложений и поэтому не так известно. Но это имеет смысл для чего-то более сложного, как CMS, где другие разработчики хотят добавить свои собственные плагины или даже изменить встроенную логику CMS.
Вы уверены, что «управляемый событиями» является правильным термином для этого?
Я думаю, что вы говорите, это инфраструктура подключаемого модуля, которая позволяет плагинам действовать, когда происходит событие (срабатывает крючок).
То, что я знаю как «управляемое событиями», – это когда приложения для настольных компьютеров хранят события в элементах пользовательского интерфейса, точно так же, как Javascript может делать для элементов HTML. Настольные приложения полностью построены таким образом. Это никогда не может быть достигнуто в веб-PHP, потому что оно полностью ориентировано на запросы.
Во всяком случае, я понимаю, что вы сейчас имеете в виду. Есть CMS и фреймворки, которые имеют это в некоторой степени – WordPress, например, и Dokuwiki.
В WordPress эти события называются действиями. Вы можете увидеть полный список в API-интерфейсе WordPress .
В DokuWiki они действительно называются событиями: система событий DokuWiki
К тому же:
Я пытаюсь определить некоторые из плюсов и минусов наличия CMS, который управляется событиями.
Плюсы очевидны: становится намного легче подключаться к системе без необходимости взломать ядро. Появится возможность писать реальные плагины.
Один большой аргумент состоит в том, что система, как правило, становится медленнее в долгосрочной перспективе, чем больше крючков есть, тем больше плагинов регистрируется на крючках. Я видел огромную работу по обслуживанию портала – удаление нескольких сотен узлов Drupal – занимать часы на сверхбыстрой производственном сервере, главным образом из-за системы крюков.
Что именно вы подразумеваете под «событием»? Означает ли это, что клиенты могут просматривать контент и будут уведомлены, когда он будет обновлен?
Если это так, то это действительно отличная идея, но реализация является амбициозной. Очевидным недостатком является то, что есть много вещей, которые могут пойти не так, в то время как модель, основанная на запросе, намного проще и, следовательно, более надежна.