I was thinking about this a bit... Let's say you have a CFC/struct that has several dozen attributes/keys. With an admission applications, you can easily have that many, or much more.
Some of the fields could be quite large, such as written essays and the such. If you loop over each of the attributes/keys and compare it to the newly-created "object", it is possible that it could eat up quite a bit of processor time. In this case, would it make better sense to have the setters keep track of which attributes have changed? I don't know if it will make much difference as you will still need to compare the old and the new just to keep track of any changes. It would just put the comparison in a different part of the code. I'm just thinking out loud here. M!ke -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Sunday, November 27, 2005 3:25 PM To: [email protected] Subject: RE: [CFCDev] logging form changes <snip> Before displaying the edit form, I would create a copy of the CFC/object that contains the most-recent information stored in your database. Then, when the form is submitted, I would create yet another CFC that contains the submitted form information. I would then created a "comparison" CFC that accepts two CFCs. This "comparison" CFC would know all about the prospect's attributes. Then, it would loop over the attributes, checking the two passed-in CFC's instance variables. If it finds a difference, then it would create a structure that contains the old and new information. Then, when the process is complete, and a struct exists, the "comparison" CFC would write the information to a log. [REF] That's exactly what we were planning. I'm glad to hear an independent voice thinks it makes sense. Do any such "diff" CFCs exist out there? I suppose it would be fairly trivial to create it, but if an example already exists, it could guide us. </snip> I"m interested in this thread, cuz i'm working on something similar. Here's another i'm considering. Instead of making a copy of the cfc, create a copy of the instance data within the Bean/BO you are using for the form. If you're using the convention to place the instance inside a struct in the variables scope of the CFC, this is dead easy to accomplish as one of the last steps in the init() using duplicate() (you'll need of course a deep copy, not just another reference). <cfset variables.originalInstance = duplicate(variables.instance)> As the bean is updated with information from the form, assuming it's a multistep process, you'll only set the instance data with your setters, not the originalInstance. Then when the form is finally submitted, you can simply loop over your instance struct and compare it to the originalInstance and when it's different, log the change. You could pass an instance of your LogChange.cfc into your Bean/BO to do this. ***** If you wanna go the 2 CFC route, you could instantiate your Bean/BO twice to 2 different variables, and once the form was submitted, pass them both into your LogChange.cfc for example, get a Memento of each instance as a struct and then loop over one and compare it to the other. Again, if you store your instance in a struct within the Bean/BO, it's easy to get the Memento. The reason i like using the memento strategy is that when the fields change or are added to later, it doesn't need modification, (except possibly within LogChange, depending on how you set that up.) If you compare instances getter by getter using the 2 cfc route, then that would need to be updated as well. And it's easy to just loop over the keys of a struct. ciao, Nando ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
