事件驱动的 CMS - 优点和缺点答案

【问题标题】：Event-driven CMS - advantages and disadvantages事件驱动的 CMS - 优点和缺点
【发布时间】：2011-04-11 23:21:40
【问题描述】：

我正在尝试确定拥有事件驱动型 CMS 的一些优点和缺点。

事件驱动并不少见。您可以在许多涉及客户端的脚本语言中看到它，例如 Actionscript、javascript、jquery。在事件及其响应发生在服务器上的 CMS 中怎么样。这种方法可能有哪些优点或缺点，以及人们可能更喜欢哪些其他方法。

附：请注意，我仅使用 Actionscript、JQ 和 JS 作为示例。您意识到，当以这种方式谈论 CMS 时，事件及其响应都是服务器端的东西。

编辑：我看到很多人说使用事件驱动没有意义，因为他们不明白它是什么。已经使用这种方法的 CMS 系统之一是 Drupal，所以相信我，这是一种现有的方式，我不会从我的 A 中提取想法。它只是意味着 CMS 的“内部”（所有服务器端的东西）是事件驱动的。核心做它的事情并定义事件。插件可以响应这些事件以添加自己的逻辑。我提到 Actionscript 作为一个例子，因为客户端是这个概念最广为人知的地方，但它也可以在服务器端，只是可能与普通应用程序不相关，因此并不为人所知。但对于更复杂的东西，比如 CMS，其他开发人员想要添加自己的插件，甚至更改 CMS 的预建逻辑，这是有意义的。

【问题讨论】：

那你会使用什么语言？ @Georg，你的洞察力如何！！！ :) 我觉得询问给出的所有示例何时都是客户端语言是合理的，据我所知，PHP 不会在没有任何其他库的帮助的情况下分派事件。此外，拥有 17k 及以上的声誉，您应该能够自己为问题带来一些答案，不是吗？那么，Georg，您认为 Dave 应该使用哪种语言？
您希望通过这种方法获得什么优势？当您说 CMS 时，我假设您的意思是基于 Web 的 CMS。无论服务器端软件如何，您的 CMS 仍会响应 HTTP 请求、生成 html 并将其返回给客户端，对吗？那么事件驱动的 CMS 将如何在该过程中提供帮助？
首先，OP明确指出他的问题与语言无关，因此您的问题并不真正相关。其次，我认为 Georg 的意思是说您的问题应该是对原始帖子的评论，而不是答案。
我仍然觉得这是一个公平的问题。如果 OP 给出了使用事件调度的服务器端语言示例，我的问题将完全无关紧要。我真的很想得到答案，而且我认为 Dave 阅读我的问题的答案可能更有趣，而不是阅读当前的 cmets，您不同意吗？
嗨，假设我使用 PHP。另请阅读我的问题中的编辑以获取更多说明。另外，我希望你们不要介意删除您的 cmets，只是为了未来的读者。帕特里克已经明白你的意思了。只是为了让未来的读者可以更轻松地阅读肉。我最终也会删除这个。

标签： php zend-framework drupal actionscript content-management-system

【解决方案1】：

您确定“事件驱动”是正确的术语吗？

我认为你在谈论的是一个插件挂钩基础设施，它允许插件在事件发生时采取行动（触发挂钩）。

我所知道的“事件驱动”是指桌面应用程序将事件存储在 UI 元素中，就像 Javascript 可以为 HTML 元素所做的那样。桌面应用程序完全是这样构建的。这在基于 Web 的 PHP 中永远无法实现，因为它完全是面向请求的。

不管怎样，我现在明白你的意思了。有些 CMS 和框架在某种程度上具有此功能 - 例如 Wordpress 和 Dokuwiki。

在 Wordpress 中，这些事件称为操作。您可以在the Wordpress Plugin API 中查看完整列表。
在 DokuWiki 中，它们确实被称为事件：DokuWiki's event system

另外：

我正在尝试确定拥有事件驱动型 CMS 的一些利弊。

优点很明显：无需破解内核就可以轻松连接到系统中。编写真正的插件成为可能。

一个很大的缺点是，从长远来看，系统往往会变得更慢，钩子越多，注册到钩子的插件就越多。我见过一个巨大的门户网站的维护操作——删除数百个 Drupal 节点——在超快的生产服务器上花费小时，主要是因为 hook 系统。

【讨论】：

+1。插件（挂钩）基础设施听起来不错且不言自明。 wiki 非常清楚什么是“事件驱动”：en.wikipedia.org/wiki/Event_driven_programming。 PHP 中没有主循环 :)
我同意，随着您添加越来越多的模块/插件，Drupal 和 Wordpress 很容易变成大而缓慢的胖大象。我见过具有数百个模块/插件的站点，这些模块/插件必须通过多个服务器、负载平衡器和前端缓存进行扩展，因为 CMS 无法满足少数访问者的需求。添加功能对于网站设计者来说非常容易，对于开发者来说，利用其他模块非常容易（我见过非常简单的具有十几个依赖项的 drupal 模块，现在想象一下你安装了十几个）。

【解决方案2】：

“事件驱动”到底是什么意思？这是否意味着客户可以观看内容并在更新时收到通知？

如果是这样，那么这确实是一个好主意，但实施是一个雄心勃勃的过程。明显的缺点是，有很多事情可能出错，而基于请求的模型更简单，因此更健壮。

【讨论】：

这意味着 CMS 的“内部”是事件驱动的，就像 Drupal 一样。核心定义了事件，插件可以响应它们以添加自己的逻辑。