dav*_*ave 11 php actionscript zend-framework drupal content-management-system
我正在尝试确定具有事件驱动的CMS的一些优点和缺点.
事件驱动并不罕见.您可以在许多脚本语言中看到它,例如涉及客户端的Actionscript,javascript,jquery.如何在CMS中服务器上发生事件及其响应.这种方法有哪些优点或缺点,以及人们可能更喜欢的其他方法.
PS请注意,我仅使用Actionscript,JQ和JS作为示例.你意识到,当用这种方式谈论CMS时,事件和响应都是服务器端的东西.
编辑:我看到很多人说使用事件驱动是没有意义的,因为他们没有得到它是什么.已经使用这种方法的CMS系统之一是Drupal,所以相信我这是一种现有的方式,我不是从我的A中提取想法.它只是意味着CMS的"内部"(所有服务器端的东西)是事件驱动的.核心做它的事情并定义事件.插件可以响应这些事件以添加自己的逻辑.我提到Actionscript作为一个例子,因为客户端是这个概念最为人所知的地方,但它也可能在服务器端,可能与普通应用程序不相关,因此不是已知的.但是对于像CMS这样复杂的东西是有意义的,其他开发人员想要添加他们自己的插件,甚至更改CMS的预先构建的逻辑.
你确定"事件驱动"是正确的术语吗？
我认为你所谈论的是一个插件钩子基础设施,允许插件在事件发生时动作(触发钩子).
我所知道的"事件驱动"是桌面应用程序在UI元素中存储事件,就像Javascript可以为HTML元素做的那样.桌面应用程序完全以这种方式构建.在基于Web的PHP中永远无法实现这一点,因为它完全是面向请求的.
无论如何,我明白你的意思了.有一些CMS和框架在某种程度上有这个 - 例如Wordpress和Dokuwiki.
在Wordpress中,这些事件称为操作.您可以在Wordpress Plugin API中看到完整列表.
在DokuWiki中,它们确实被称为事件:DokuWiki的事件系统
此外:
我正在尝试确定具有事件驱动的CMS的一些优点和缺点.
优点是显而易见的:无需破解核心就可以更轻松地连接系统.可以编写真正的插件.
一个很大的缺点是,从长远来看,系统往往变得越慢,钩子越多,并且钩子上注册的插件越多.我已经看到一个巨大的门户维护操作 - 删除了几百个Drupal节点 - 在超快速生产服务器上花费数小时,主要是因为钩子系统.
“事件驱动”到底是什么意思？这是否意味着客户可以观看内容并在内容更新时收到通知？
如果是这样，那么这确实是一个好主意，但实施起来却是一个艰巨的过程。明显的缺点是，有很多事情可能会出错，而基于请求的模型要简单得多，因此更健壮。