Most Elgg programmers are by now familiar with extending or replacing existing views, or providing new views for new objects etc.

But what if you just wanted to make a simple tweak to an existing view – for example to replace all instances of rude words in a feed article, or to turn passive links into active ones?

Well, fortunately Elgg provides a post processing hook for views which can do just that.

After every view has been generated, the framework will trigger a plugin hook called “‘display’, ‘view’”. This hook is passed a parameter ‘view’ which contains the name of the view being processed (eg. object/blog).

The contents of the view are passed in the $returnvalue variable which you can perform any processing on before returning it from the hook.

I have just uploaded a Trac tags plugin to the Elgg community site which provides a good example of this.

The Trac tags plugin is a tiny plugin which uses the views post processing hook to turn Trac links (e.g. #xxxxx for tickets and [xxxxx] for changesets) into active links into your repository, and here’s how – first we register the hook:

function tractags_init()
{
....
// Register our post processing hook
register_plugin_hook('display', 'view', 'tractags_rewrite');


// define views we want to rewrite codes on (means we don't have to process *everything*)
$CONFIG->tractags_views = array(
'object/thewire',
'object/blog'
);

....
}

Then in our handler looks something like this:

function tractags_rewrite($hook, $entity_type, $returnvalue, $params)
{
global $CONFIG;

$view = $params['view'];

if (($view) && (in_array($view, $CONFIG->tractags_views)))
{
// Search and replace ticket numbers
$returnvalue = preg_replace_callback('/(#)([0-9]+)/i',
create_function(
'$matches',
'
global $CONFIG;

return "<a href=\"{$CONFIG->trac_baseurl}ticket/{$matches[2]}\">{$matches[0]}</a>";
'
), $returnvalue);

// Search and replace changesets
$returnvalue = preg_replace_callback('/(\[)([0-9]+)(\])/i',
create_function(
'$matches',
'
global $CONFIG;

return "<a href=\"{$CONFIG->trac_baseurl}changeset/{$matches[2]}\">{$matches[0]}</a>";
'
), $returnvalue);

return $returnvalue;
}
}

I’m sure you will be able to come up with some much more interesting uses!

Image from the Trac project.

Broadly speaking I agree with him. The two main players – Bugzilla and Trac – are both lacking. Bugzilla’s interface has notable usability issues, and trac too is somewhat lacking.

In both cases however, the core functionality of what a bugtracker actually does – a prioritised and editable todo list – works perfectly.

The problem is interface.

How do we create one that is useful to both developers (who need quite detailed settings) and end users (who need a simple interface and in many cases need a certain amount of hand holding in order to fill in a report which is useful to the developer)?

Thinking back to my usage of both Bugzilla and Trac – the answer is that we don’t.

Let me explain: I have used both Bugzilla and Trac in anguish on large projects for many many years, but I have hardly ever used the default interface – currently I use the excellent Mylyn (nee Mylar) for Eclipse. For me a bugtracker is a central todo list accessible from anywhere – combined with a central svn repo it becomes possible for me to continue to do work anywhere there is a computer and internet connection… invaluable if you spend any amount of time travelling.

It seems to me that a good approach would be to have the bug tracker entirely API driven (more so than it is now – which in many cases is a later bolt on), that way it would be possible to provide a variety of expert interfaces for developers and a simplified interface for end users – rather than having one interface try and do it all.

This interface should hold peoples hand and ask specific targeted questions to encourage non-programmers to provide reports which will be useful to developers.

Tagging (and tag clustering) could be a useful technique to then group issues together – making it easy to find related issues and to spot duplicates.

Building on some social technology to establish relationships between issues, comment around them and attach files and other media could also be useful.

If the underlining engine is the same this shouldn’t involve too much in the way of work duplication, but will allow for tighter integration with the tools and workflow people actually use.