Event-driven CMS - advantages and disadvantages

Question

I'm trying to identify some of the pros and cons of having a CMS that is event driven.

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.

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.

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.

Answer 1

What language would you use then?

@Georg, how perceptive of you!!! :) I find it reasonable to ask when all the examples given are client side languages and I far as I know PHP doesn't dispatch events, without the help of any additional library. Furthermore, with a reputation of 17k & over , you should be able to bring some answers to the question yourself, shouldn't you? So, Georg, what language do you think Dave should use?

Answer 2

What exactly do you mean by "event driven"? Does it mean, that clients can watch content and will be notified, when it is updated?

If so, than this is really a great idea, but the implementation is an ambitous undergoing. The clear disadvantage is, that there are tons of things, that can go wrong, while a request based model is much simpler and thus more robust.

Answer 3

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).

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.

Anyway, I see what you mean now. There are CMSs and frameworks that have this to some extent - Wordpress for example and Dokuwiki.

• In Wordpress, these events are called actions. You can see a full list in the Wordpress Plugin API.

• In DokuWiki, they are indeed called events: DokuWiki's event system

In addition:

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.

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.