Comment and TrackBack listeners
With comment spam being a hot topic at the moment, I'd like to briefly tell you about comment listeners, a new feature for Pebble 1.7, that provides a way for you to write code that is called whenever something happens to a comment. To be more precise, the following events will trigger comment listeners to be called.
- A comment is added.
- A comment is deleted.
- A comment is approved.
- A comment is rejected.
package pebble.event.comment;
/**
* Implemented by classes wanting to be notified of comment events.
*
* @author Simon Brown
*/
public interface CommentListener {
/**
* Called when a comment has been added.
*
* @param event a CommentEvent instance
*/
public void commentAdded(CommentEvent event);
/**
* Called when a comment has been removed.
*
* @param event a CommentEvent instance
*/
public void commentRemoved(CommentEvent event);
/**
* Called when a comment has been approved.
*
* @param event a CommentEvent instance
*/
public void commentApproved(CommentEvent event);
/**
* Called when a comment has been rejected.
*
* @param event a CommentEvent instance
*/
public void commentRejected(CommentEvent event);
}
The CommentEvent class extends the java.util.EventObject class and allows you to get access to the Comment object that caused the event to fire. In addition to this interface, there's a CommentListenerSupport class that provides default (empty) implementations of the callback methods. You can subclass this and override only the callback methods you are interested in. TrackBack specific versions are available in the pebble.event.trackback package.
At the moment, when a new comment is added, you can tell Pebble to send an e-mail notification to the blog owner and everybody that left their e-mail address. This is done through the blog properties page and is an "on or off" feature. With Pebble 1.7, this functionality has moved to a comment listener implementation that you can choose to use, not use or modify to suit your own needs. The same is true of e-mail notifications to the blog owner upon new TrackBacks arriving.
One of the earliest improvements that I raised in JIRA was PEB-4, the ability to moderate comments. As you've probably noticed from the above interface definition, comments and TrackBacks can now be approved and rejected. There's also a pending state. By default, all comments and TrackBacks start out life as approved so that when upgrading to Pebble 1.7, you won't see any functional difference. Comments can still be added and will appear on your blog as normal. Ditto TrackBacks. However, comment and TrackBack listeners will let you customize this behaviour.
For example, one of the comment listeners that will ship with Pebble can immediately set the status of a new comment to pending and send the blog owner an e-mail asking for them to approve the new comment. On approval, the notification e-mail is sent out as usual. To support this, some new pages have been built that will let a blog owner or contributor manually approve or reject a comment. A link to these pages is included in the e-mail and provides a basic level of comment moderation. Other examples of listeners that have been written include one that deletes comments when they have been marked as rejected. Of course, you aren't limited to human comment moderation and you could write a listener that approves or rejects a comment based upon IP address, content, rate of comment submission, number of comments already added, etc. The list is endless and this all applies to TrackBacks too.
Another aspect is how to display or not display unapproved comments. Rather than assume that everybody is going to want to hide unapproved comments, a blog entry decorator can be used to remove (hide) comments if the current user isn't a blog owner or contributor. Something I've tried to do with Pebble is keep the user interface as simple as possible and that's why you'll see links to approve and reject next to comments that are in the pending state, if you're logged in.
I think that I'm pretty much there with the infrastructure to support this but I there are a couple more things that I need to work out (e.g. where to store user definable parameters for plugins). If there's anything else you'd like to see, please let me know.
Simon is a hands-on software architect and has a BSc (Hons) in Computer Science from the University of Reading. Over the past 12 years, he’s been involved in projects ranging from rich desktop clients and web applications through to highly scalable distributed systems and service-oriented architectures; predominantly within the finance industry. He's also undertaken consulting and training roles with a broader focus on people, process and technology.

