我正在尝试确定事件驱动的 CMS 的一些优缺点.
I'm trying to identify some of the pros and cons of having a CMS that is event driven.
事件驱动并不少见.您可以在许多涉及客户端的脚本语言中看到它，例如 Actionscript、javascript、jquery.在事件及其响应发生在服务器上的 CMS 中如何.这种方法有哪些优点或缺点，以及人们可能更喜欢哪些其他方法.
Event driven is not uncommon. You see it in many scripting languages like Actionscript, javascript, jquery that involve a client. How about in a CMS where the events and their responses happen on the server. What advantages or disadvantages might this approach have, and what other approaches are there that people may prefer more.
附言请注意，我仅将 Actionscript、JQ 和 JS 用作示例.您会意识到，当以这种方式谈论 CMS 时，事件及其响应都是服务器端的内容.
P.S. Please note that I use Actionscript, JQ, and JS as an example only. You realize that when talking about a CMS this way, the events an their responses are all server side stuff.
编辑:我看到很多人说使用事件驱动是没有意义的，因为他们不明白它是什么.已经使用这种方法的 CMS 系统之一是 Drupal，所以相信我这是一种现有的方式，我不会从我的 A 中提取想法.它只是意味着 CMS 的内部"(所有服务器端的东西)是事件驱动的.核心做它的事情并定义事件.插件可以响应这些事件以添加自己的逻辑.我以 Actionscript 为例，因为客户端是这个概念最广为人知的地方，但它也可以在服务器端，只是可能与普通应用程序不相关，因此不太为人所知.但对于更复杂的东西，比如 CMS，其他开发人员想要添加自己的插件，甚至更改 CMS 的预构建逻辑，这是有意义的.
Edit: I see a lot of people saying that it makes no sense to use event-driven as they don't get what it is. One of the CMS systems that already use this approach is Drupal, so trust me it's an existing way, I'm not pulling ideas out of my A. It just means the "internals" of the CMS (all the server-side stuff) are event-driven. The core does its thing AND defines events. Plugins can respond to those events to add their own logic. I mentione Actionscript as an example because client-side is where this concept is most known, but it can be on the server-side too, just maybe not as relevant for normal applications and so not as known. But it makes sense for something more complex like a CMS where other developers want to add their own plugins or even change the pre-built in logic of the CMS.
您确定事件驱动"是正确的术语吗?
Are you sure "event-driven" is the correct term for this?
我认为您在谈论的是插件钩子基础结构，它允许插件在事件发生时(触发钩子)起作用.
I think what you are talking about is a plugin hook infrastructure that allows plugins to act when an event takes place (a hook is triggered).
我所知道的事件驱动"是指桌面应用程序将事件存储在 UI 元素中，就像 Javascript 对 HTML 元素所做的那样.桌面应用程序完全以这种方式构建.这在基于 Web 的 PHP 中永远无法实现，因为它完全面向请求.
What I know as "event driven" is when desktop applications store events in UI elements, just as Javascript can do for HTML elements. Desktop apps are built entirely that way. That can never be achieved in Web-based PHP because it is entirely request oriented.
无论如何，我现在明白你的意思了.有些 CMS 和框架在某种程度上具有此功能 - 例如 Wordpress 和 Dokuwiki.
Anyway, I see what you mean now. There are CMSs and frameworks that have this to some extent - Wordpress for example and Dokuwiki.
在 Wordpress 中，这些事件称为操作.您可以在 Wordpress 插件 API 中查看完整列表.
在 DokuWiki 中，它们确实被称为事件:DokuWiki 的事件系统
In DokuWiki, they are indeed called events: DokuWiki's event system
另外:
我正在尝试确定事件驱动的 CMS 的一些优缺点.
I'm trying to identify some of the pros and cons of having a CMS that is event driven.
优点是显而易见的:无需破解核心就可以更轻松地连接到系统中.编写真正的插件成为可能.
The pros are obvious: It becomes much, much easier to hook into the system without having to hack the core. It becomes possible to write real plugins.
一个很大的缺点是，从长远来看，钩子越多，系统越慢，并且在钩子上注册的插件也越多.我见过大型门户的维护操作——删除数百个 Drupal 节点——在超快的生产服务器上花费小时，主要是因为钩子系统.
One big con is that the system tends to become slower on the long term the more hooks there are, and the more plugins are registered to the hooks. I've seen a huge portal's maintenance operation - the deletion of several hundred Drupal nodes - take hours on a ultra-fast production server, mainly because of the hook system.
这篇关于事件驱动的 CMS - 优点和缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！