Building an audit engine with Zend Framework

Posted April 3, 2008, 7:53am In: Dragonfly R&D, Zend Framework

Part of what I love with ZF is the ease at which I can extend it to do what I need.

For instance, recently I was developing my app (codenamed Karmba) - something I needed to do is to be able to log every transaction, and at any time restore a version of information.

Let’s say for instance, that I have a blog - I know, I know, everyone uses that as an example, but let’s stick with something familiar, okay - and within my admin, I want to edit an entry. I start with my controller.

Disclaimer: This post is based on a real application, but isn’t all of the actual code. It is not plug and play; expecting this code to work out of the gate does not reflect what I’m trying to do.

For reference, DomainObject is just a convenience class - you can easily replace it with Zend_Db_Table

Now, let’s take a look at the Factory itself. A majority of this should be familiar to you.

Now, to illustrate my point, we create an object, Blog_Post - within Blog_Post there’s as much or as little as we need to alter the data.

Now this is where we start to see a little bit of the magic happen. Db_Table_Row (or another suitably named object) accesses functions that are called by Zend based on certain events. The event that I want to illustrate here is _postUpdate - an event that fires AFTER the object is updated. Now, a bit of hacking is required to get this to work. If you don’t know what _cleanData, _data or _modifiedFields are and how they’re used, a lot of this won’t make sense to you.

Now, inside AuditFactory is where we log all our transactions. We can revert entire objects or alternatively pick and choose what we update. That’s why every field gets a new object.

And that’s it!

This example proves how powerful the Zend_Db component of the Zend Framework is - and how contrary to popular belief - easy it is to extend existing functionality in a real world environment.

Audit factory doesn’t need to log to a database either. You could easily alter the class to the log entries to disk, or send an email, et cetera.

Feel free to comment, or expand on what I’ve said.

This entry was posted on Thursday, April 3rd, 2008 at 7:53 am and is filed under Dragonfly R&D, Zend Framework. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

3 Responses...

Adam

Nice. So this would make a row in the _audit table for each column modified.

I plan on doing something like this for an Undo Manager in my web application. Thanks for the proof of concept!

Ryan Brooks

@Adam

An “undo manager” is exactly the intent. You can revert an entire transaction, or just a column. Let’s say you make a post, edit it, and decide later on the edit to the title you made was wrong. You can revert to the former title, without changing the rest of the record. THAT is power.

Jani Hartikainen

This is a very nice idea. I actually have something slightly similar in the CMS I’m developing using Zend Framework and Doctrine.

This would be easier if Zend_Db had an interface similar to Doctrine’s. Since Doctrine supports event listeners, you can just create a listener and attach it to your model.

Leave a reply...

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>