事件驅動的CMS - 優點和缺點

Question

我試圖找出一些事件驅動的CMS的優點和缺點。

事件驅動並不少見。你可以在許多腳本語言中看到它，例如涉及客戶端的Actionscript，javascript，jquery。在CMS中，事件及其響應在服務器上發生的情況如何？這種方法可能有哪些優點或缺點，以及人們可能更喜歡哪些其他方法。

P.S.請注意，我僅使用Actionscript，JQ和JS作爲示例。你意識到，當以這種方式談論CMS時，事件和他們的反應都是服務器端的東西。

編輯：我看到很多人說，這是沒有意義的使用事件驅動的，因爲他們不明白它是什麼。已經使用這種方法的CMS系統之一是Drupal，所以請相信我這是一種現有的方式，我不會將想法從我的A中抽出來。它僅僅意味着CMS的「內部」（所有服務器端的東西）是事件驅動的。核心完成它的事情並定義事件。插件可以響應這些事件來添加自己的邏輯。我提到Actionscript作爲一個例子，因爲客戶端是這個概念最爲人所知的地方，但它也可能在服務器端，也許與正常應用程序不相關，因此不像已知的那樣。但對於其他開發人員想要添加自己的插件甚至更改CMS的預置邏輯的CMS等更復雜的內容來說，它是有意義的。

Answer 1

究竟你的「事件驅動」是什麼意思？這是否意味着客戶可以觀看內容，並在更新時得到通知？

如果是這樣，比這確實是一個偉大的想法，但實施是一個ambitous經受。明顯的缺點是，有很多事情可能會出錯，而基於請求的模型更簡單，因此更加健壯。

Answer 2

確定「事件驅動」是正確的術語，這一點？

我想你所談論的是一個插件掛鉤的基礎架構，允許使用插件來當一個事件發生（鉤被觸發）採取行動。

我知道什麼是「事件驅動」是當桌面應用程序商店事件的UI元素，就如JavaScript可以爲HTML元素做。桌面應用程序完全是這樣構建的。這在基於Web的PHP中永遠無法實現，因爲它完全是以請求爲導向的。

無論如何，我明白你的意思了。有些CMS和框架在某種程度上具有這種功能 - 例如Wordpress和Dokuwiki。

• 在Wordpress中，這些事件被稱爲動作。您可以在the Wordpress Plugin API中看到完整列表。

• DokuWiki中，他們確實叫事件：DokuWiki's event system

另外：

我試圖找出一些有CMS的利弊是事件驅動。

優點是顯而易見的：它變得更容易掛鉤到系統而無需破解核心。編寫真正的插件成爲可能。

一個重要的問題是系統的長期趨勢會變得越來越慢，鉤子越多，插件越多。我見過一個巨大的門戶維護操作 - 刪除幾百個Drupal節點 - 在超高速生產服務器上花費小時，主要是因爲鉤子系統。