RE: [CFCDev] logging form changes

[Dawson, Michael]

First, I assume you have a primary record for each prospective student's application.  If so, I would add the following fields to that record: 1. ApplicationCreatedDate 2. ApplicationLastModifiedDate 3. ApplicationAdmitDecisionDate 4. ApplicationStudentAcceptDate   I would add these fields since they are very important to the record itself.  They add so much value to the record yet are almost meaningless by themselves.  Also, there will only be *one* ApplicationCreatedDate, etc.  However, changes to a prospect's phone number could change multiple times.   Then, I would log all other changes as you mention.  For example, the prospect changes his contact phone number.  That would be a good candidate for the logging.  Store the old and the new values in the log entry as you suggest.   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.   Before I would go to the trouble of all this work, I would first make sure that you *really* need to log this information. ;-)  We have many requests from our admission department that want the pie-in-the-sky projects.  We eventually talk them into more-reasonable projects that can be completed in a timely manner with fewer resources.   We are planning on rewriting our entire application process, but we have not even planned on doing the intermediate logging since we only care about the final result.  However, in our case, we let the prospects update their application as many times as necessary before they submit the application.  This could take place over hours, days or even weeks.   M!ke From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Flynn, Robert E Sent: Saturday, November 26, 2005 9:35 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] logging form changes Hey Mike,   Let me give a broader picture of what we are up to and you can see why I don’t think saving the FORM scope will do what I need. Of course we may be totally off-base. If so, please say so.   Our app contains academic applications. Multiple individuals update the records as various pieces of the applications (transcripts, letters of recommendation, admit decisions, etc.) come in at random times. What we are looking to do is to display a transactional history for each application. Our thinking is that we would write to a log the page ID, record ID, time, logged-in user, previous value and new value of anything that changes for the record. This is log would list everything from the date the application was created, when supporting documents are received, to when an admit decision was made to when the student accepts. We thought the easiest way to do this under our existing db structure would be to examine each page for what has changed when updated. Certainly open to suggestions for something simpler.   Thanks!   ~Bob ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org