It has been a busy few weeks. Those of you who have been following the cut and thrust of development and tracking SVN will have noticed a fair few extra features and functionality and a lot of core code changes – extra tools, new activity viewing code, many speed improvements, a central entity icon API, bug fixes etc.

A lot of people have been picking up the code and contributing. The Community site we launched earlier this month seems to have been a big hit with people and we are seeing some really quite useful stuff fall out of the mix.

As we approach the release of Elgg 1.1 I thought it would be a good time to talk a little bit about what I call “doing things the Elgg way”.

Elgg is built to be modular and pluggable, so this means always thinking about how you can let others safely hook in and extend the way your code works.

We make extensive use of the events system, so for example when an entity is created or updated it triggers an event. Other bits of code can chose to listen to this event and do something.

This is for example how logging works.

The Elgg system log simply listens to events in the system, and when an event is triggered on an object which can be logged it writes the appropriate entry in the system log.

This can be then further processed by the River or Activity viewer, which brings us rather nicely into the subject of views (which we have talked a bit about before).

The activity stream and the river both work off the system log and use the views system. What happens is that when either of these is displayed the code looks to see if it has a view to render a given item in the log, and if so it renders the event.

This is very flexible, since it means that any plugin can come along and add and extend the river or activity stream – adding custom views for its own entities or extending other entities – all of which without touching a single line of core code.

This is a pretty big win, and this is part of what it means to develop the Elgg way.

The lesson this week has got to be “Profiling is a Good Thing”. While working on the new Elgg community site this week, it quickly became clear that the way the River code was written was horribly inefficient.

So, I had to optimise it.

Unfortunately this necessitated a schema change to the system log (a good test for the Elgg update scripts). It also required some changes to the way the river views are constructed.

The details of these changes are documented over here. Turns out to be a bit of a blessing in disguise; letting us speed up the river while at the same time increasing the number of events a plugin can hook into as well as standardising the views hierarchy.

The down side is that after the upgrade site rivers will appear to be blank – this is because while the system log is still there, the format of the log and the way the river code hooks into it has changed.

The change also means that plugins which hook into the river will also need to modify their views hierarchy slightly.

You are probably all aware of the concept of the River in terms of social networking platforms; being able to see what your friends have been up to as a list of events – what they have been doing, who they have made their friend etc.

This feature – made popular by the facebook “mini-feed” – has become one of the things that users expect from any platform they use and is rather compelling.

What if you want to see what they have been doing on other networks? Would it not be a pretty neat thing to be able to subscribe to their activity in order to receive updates about what they have been up to in a similar way as you would be able to subscribe to their blog via RSS?

This turns out to be a simple yet powerful use case for OpenDD, and this is how we’re doing it in the new version of Elgg.

I talked a bit about how the river was implemented in Elgg 1.0 in previous articles. In a nutshell we have a system log which stores events as they happen in terms of a simple relationship, e.g. “User X CREATED BlogPost”, “User X UPDATED profile”, etc.

Once you have that information it becomes very easy to mine that for extra information and turn it into a River event. Essentially, a plugin would create a view on the specific event and entity and then be able to render it as a river item and provide new views on existing data.

If you remember, I also talked about how I changed the river code to use this thing called ElggRiverStatement, which lets you construct the river in a much more linguistic way and also provides all the information needed by the river views.

Creating a “Friends activity elsewhere” syndication view becomes quite easy. Essentially, all you need to do is export the system log for a user, which you can do very easily using OpenDD as a sequence of OpenDD Relationships. This is because “User X CREATED BlogPost” can be thought of in terms of a relationship.

Once this is done, an aggregation client can retrieve the feeds of all the friends that you’ve signed up to and then sort the relationships by published data, and then – because everything has a UUID – you can then drill down and pull the extra information required – details about the user who initiated the action, the object the event was performed on, metadata etc.

This essentially means you can construct a succession of ElggRiverStatement objects out of an OpenDD feed. This is quite cool, because it means you can take those objects and inject them into the already existing river views and get a river entry back. This means that for absolutely zero extra work, every plugin has the ability to render a “Friend elsewhere” event… and it becomes seamless!

Additionally, you can look to digging further and getting extra information about the entities involved and actually be able to see the entity in question – whether by linking to the entity elsewhere or using the information you have about it to render it locally.

This is quite a simple example, but it shows some of the power of OpenDD. Additionally, I should point out that since OpenDD is atomic, you don’t ever have to get all the information in one go!