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.