Table of Contents

Event Driven Design

Author: Helgi Žormar Žorbjörnsson, helgi _AT_ trance _DOT_ is
Date: 22 May, 2005

Main part

When a project like Jaws gets bigger people start to ask for more complex things both core and gadget wise, which is a thing we most of the time do not want to do, which leaves our users often angry, dissapointed or in the worst case they leave us for another system that’s ready to sustaine big and heavy gadgets/modules, which is not very idol for us since we want of course to keep a big market and be useful for a broad audience.

We could tell them to fork of our gadgets and make a complex version out of them, but that means they have to maintain that and keep track of our changes and etc which is a big headache compare to just maintain a little extra gadget that’s plugged into our simple gadget and combined they are a complex gadget ;)

So what’s the solution against lazy and demanding users in this case ?
Event driven design! :-)

Before doing any introduction, than I want to make it clear that I want us to use a PEAR package called Event_Dispatcher [1] … It originally was proposed as a PHP5 solution but was made into a PHP4 one so everyone can benefit from it, so we will see a PHP5 only package in the future, which is good when we change over to PHP5 only our selfs

For a short introduction made by the authors and small set of examples look at [2], [3] and [4]. There are also available slides and they are located at [5] and the example code that goes with that at [6]

But I will now explain it with my own words and a bit more Jaws orient.

What this will mean for us is that we’ll be able to make gadget interact in much easier way then we can now and the best part is, the gadgets do not have to know about each other!

This does not mean tho that we can start sending data between gadgets or anything like that, as the examples show and the introduction by the authors says, it’s about sending notifications, like in one of the examples, it can make a logger attach him self to a onLoggin event, and when a user logs in the user class triggers the onLoggin, which gets sent to Event_Dispatcher which than sends it on to the Logger class, in theory the gadgets never know about each other.

But in a way I lied about what I said above, there is a function called getNotificationObject() that gives you back a reference of the object that sent the notification, so if you sent it with your user class than this would return a reference to the user class, which will allow you to do some funky stuff and in fact move data between the gadgets :P

There’s also a function called getNotificationInfo() which gives you some additional info about the notification that was sent but I my self haven’t tried it and I’m not 100% what kind of info it really gives you. :S

Another example would be if we’d make a user blocker script, i.e. to ban the users, instead of start fiddling around in the JawsUser class to implement it, than we’d just register the the blocker class with the onLoggin notification and when the user logs in than onLoggin is sent like I said above, user blocker gets it and sees that the user is banned and voila user blocker can cancel the notification which we’d check for in our user class and if the notification is canceled (the user class doesn’t have to know what canceled it, just that it was canceled) and the user is logged straight out (or not just logged in at all, this could happen before the user is registered and given a session)

It can also be if that the user fails to login that we send out onFail and a logger picks it up and logs that.

Really many things that can be done with this and we have to think less about it when we connect gadgets together or make bridges between them and in fact share a bit of data between them with out the need to reimplement things and have a lot of code duplication.

I my self haven’t used this class that much, just a little for LiveUser [7] where it is working very well and is actually great to have such a thing in a auth/perm system, we also made up a little get started guide for observers (i.e. event dispatcher stuff) and it’s located at [8] but I do think we’re making both our life and the gadget developers life easier if we implement event drive design to Jaws.


  /var/www/wiki/htdocs/data/jaws/proposals/event_driven.txt · Last modified: 2007/11/02 16:27