Подтвердить что ты не робот

Управляемые событиями CMS - преимущества и недостатки

Я пытаюсь определить некоторые из плюсов и минусов наличия CMS, который управляется событиями.

Приведенное событие не является чем-то необычным. Вы видите это на многих языках сценариев, таких как Actionscript, javascript, jquery, которые связаны с клиентом. Как насчет в CMS, где события и их ответы происходят на сервере. Какие преимущества или недостатки может иметь этот подход, и какие другие подходы существуют, что люди могут предпочесть больше.

P.S. Обратите внимание, что я использую ActionScript, JQ и JS только как пример. Вы понимаете, что когда речь идет о CMS таким образом, события и их ответы - все на стороне сервера.

Изменить. Я вижу, что многие люди говорят, что нет смысла использовать управляемые событиями, поскольку они не получают того, что есть. Одна из систем CMS, которые уже используют этот подход, - это Drupal, поэтому поверьте мне это уже существующий путь, я не вытаскиваю идеи из своего A. Это просто означает "внутренности" CMS (все серверные вещи) управляются событиями. Ядро делает свою вещь AND определяет события. Плагины могут реагировать на эти события, чтобы добавить свою собственную логику. Я упоминаю ActionScript как пример, потому что клиентская сторона - это то, где эта концепция наиболее известна, но она также может быть на стороне сервера, возможно, не так важна для обычных приложений и поэтому не так известна. Но это имеет смысл для чего-то более сложного, как CMS, где другие разработчики хотят добавить свои собственные плагины или даже изменить заранее встроенную логику CMS.

4b9b3361

ОТВЕТЫ

Ответ 1

Вы уверены, что "управляемый событиями" является правильным термином для этого?

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

То, что я знаю как "управляемое событиями", - это когда приложения для настольных компьютеров хранят события в элементах пользовательского интерфейса, как Javascript для HTML-элементов. Настольные приложения полностью построены таким образом. Это никогда не может быть достигнуто в веб-PHP, потому что оно полностью ориентировано на запросы.

В любом случае, я понимаю, что вы имеете в виду сейчас. Есть CMS и фреймворки, которые имеют это в некоторой степени - Wordpress, например, и Dokuwiki.

Кроме того:

Я пытаюсь определить некоторые из плюсов и минусов наличия CMS, который управляется событиями.

Плюсы очевидны: становится намного легче подключиться к системе без необходимости взломать ядро. Появится возможность писать реальные плагины.

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

Ответ 2

Что именно вы подразумеваете под "event driven"? Означает ли это, что клиенты могут просматривать контент и будут уведомлены, когда он будет обновлен?

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