I’m planning on building an interceptor (or something), which i’ll happily pass back to Forgebox Community, which will automatically build an audit trail on save.
I’m looking for some advice, or a good starting point. What i want to do, is have something in my code (it might just go into the virtual service) which when i save an object (any object), it will populate a couple of properties (if exists), e.g. dateCreated / dateModified & AddedBy / UpdatedBy. I might then extend it to also push the contents of Message Box to a table to record ‘Recent Activity’, or something, but that can come later.
So i think i’m looking for a hook like onAfterSaveSucess, or onBeforeSave or something, and wanted to get some pointers, as i’ve probably missed something.
Let me know if you have any questions!
Audit trails are best handled at the ORM Event Handling, which is usually best at the global event layer.
I should have added that all these events can be intercepted, and can be found in the EventHandler.cfc in the core ColdBox folder, in ORM.
Oh cool, so i can just create an interceptor which listens for ORMPreSave, and adds the properties to the entity?
I’m a bit new to Interceptors, so i’ll go read the docs for a bit, but any tips would be great!
Written a few that may or may not help
But don’t just rely on save, you want to do the others as well.
Great, thanks Andy.
One last thing, if i wanted to use an IsActive column (or DateDeleted) is there somewhere at the global level i can update to have the whole application respect that column (if exists)?
Yes you can, I haven’t done it for awhile now. I went looking for the code I used, but can’t seem to find it.
But basically the update has the entity passed to it, both as before and after data, you could then do a check if it exists before doing what you need to do.
I’m not sure how involved you’re wanting to get, but in the past I’ve added extra meta data to each entity which defines the rules for that particular entity in regards to audit tracking. I’ve then created a single, global interceptor which listens to many of the events (ORMPreUpdate, ORMPostSave, ORMPreDelete, etc.) and processes each event based on the rules defined for the given executing entity.
For persistence, I just used a simple scheme for building SQL queries based, again, on the rules defined in the entities themselves. Not necessary for what you’re wanting to do, but important to implement if things get complex and you need to avoid session collisions.
In my case, the audit history is writing data about the changes to the entities to other tables, so maybe not exactly the same as what you’re wanting to do. However, the principle is the same and shows that the events which CF and ColdBox expose for ORM can be leveraged to do a lot of really cool stuff.