Following from a similar post, where I packaged up my standard web services libraries to avoid repeating myself, I decided to do the same for Events and triggers.

Events provide a very powerful, flexible and simple way of providing hooks for other code to attach to, in a loosely coupled way. I’ve been using event driven development in my PHP code for years, way back since the first days of Elgg. In Elgg, events and triggers proved to be one of the frameworks most powerful, and a major factor in its success, allowing plugin developers to easily change core functionality without changing a line of core code.

Anyway, I’ve used Events in one form or another in pretty much every framework since, and I’ve found myself increasingly cutting and pasting code around, so I figured it’d be sensible to package this up into a reusable library as well. Although it is designed to be simple, the library is pretty powerful.

One particularly useful feature is that event listeners can include regexp!

Triggering an event…

If you were writing a framework that had users for example, and you wanted to allow plugin authors to hook in and do something when a new user is created, you might do something like this in your registration code…

function registerUser($username, $password) {

    // User creation code here

    // Ok, now tell everyone that a user has been created
    \simple_event_dispatcher\Events::trigger('user', 'create', ['user' => $new_user]);


Listening to an event…

So, if you wanted to listen to the user creation event inside your plugin…

// Register an event for every time a user is created
\simple_event_dispatcher\Events::register('user', 'create', function($namespace, $event, &$parameters) { 

    // Your code here


You can replace any part of the $namespace or $event string in Events::register (‘user‘ and ‘create‘ respectively in the example above) with regular expression. So, you could, for example, replace ‘user‘ with ‘*‘ to listen with any create event.

Code on GitHub, have fun!

» Visit the project on Github...

I can barely contain my excitement, but we are now only a few hours away from the start of the Barcamp Transparency event weekend!

The weekend kicks off tonight at 7pm BST (6 GMT) with our virtual eventfind us on Friendfeed!

Tomorrow, those of you who are coming down the night before are welcome to join us in the Gardener’s Arms from about 7pm for food, beers and a bit of socialising… look out for the group with Barcamp Transparency posters (thanks Ben Werdmuller for designing those!).

Don’t forget to @mapkyca on Twitter if you get lost!

Finally, the main Barcamp Transparency event kicks off at 10am on Sunday in the Oxford University Club on Mansfield road. Detailed instructions for getting there can be found on the Barcamp Transparency website!

See you there!

Federated networks are the future for social networks. Realistically, nobody is going to come along any time soon to challenge the big players like Facebook. But what we can do is allow users to move themselves and their data seamlessly between niche networks, or better yet provide a way of linking up users and data between networks.

There are technologies around that are all working on bits of the puzzle; OpenID, OAuth etc. I think OpenDD solves a key part of the problem by providing a way to link between and move arbitrary data about in a generic and easily understandable way.

In my last post I illustrated the syndication usecase for OpenDD; how you can subscribe to a feed for a user and get a list of their activity in the form of a river. One important thing that I forgot to mention of course is there is absolutely no reason why you couldn’t use the same technique to subscribe to and receive updates about any resource.

Another powerful use case for OpenDD is its use in a live push context, and that is what I’m going to write a bit about today. Now we have already touched on the fact that OpenDD components are all atomic; they do not require a great deal of context or state around them, so for example if you establish a relationship between two entities you do not need to include the complete description of the entities in question – just the relationship.

In the latest specifications I have introduced the concept of being able to unset and remove things, so as well as creating a relationship it is also possible to remove it. This turns OpenDD into quite a powerful tool in your arsenal.

If you take Elgg as an example, Elgg has an events system which we have touched on in previous articles and as well as providing a syndication of an events log in the form of a river, we can also look at pushing those events as they happen out to interesting parties as a sequence of OpenDD components.

So, for example, you could request to be notified when a user joins a group or when something changes on a file (or indeed any other resource) and this can then be pushed out to you in a way that is simple to understand – and again, because we have the concept of an UUID, it isn’t necessary to have the complete context in order for the message to be useful. Everything else can be worked out.

So, using OpenDD, it is now possible to subscribe to users and resources on different networks and receive a feed of updates, but it is also now possible to push messages between networks in an open way that is understood by both platforms.

One of the cool things you can do with that is for example Sharing. In one network you could create a resource, for example a photo of you at a party or a URL you were interested in. Then you could select between the friends on the network you are in but also from friends elsewhere to share the resource with.

The user on the foreign network would then receive an OpenDD push update message saying that you have created a resource and have shared it with them (or rather the platform would receive and interpret it), and because users and the resource are all addressed by UUID the user would be able to see this seamlessly on their own network.