|
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 [REF] Have most of those already. There is no
lastModifiedDate because once an applicant submits the application, they can’t
touch it anymore. Every additional bit of information we add would change a
last modified date. That is why we want to track those changes (and the dates
they are made). A single lastModifiedDate would not be particularly meaningful
or helpful. 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. [REF] In fact they are not meaningless to us as we track the
“timeline” of the application so that we can see what phase an
application is in and where it matches our communication milestones. If they
accept after a certain milestone we go back and give them past communications
they may have missed. Also, there will only be *one*
ApplicationCreatedDate, etc. However, changes to a prospect's phone
number could change multiple times. [REF] Even those dates can change. Some students accept,
then, due to visa difficulties, ask for a deferral, so their decision, in
effect, changes. Then they may accept for the following year or decline, so it
changes again. While demo info like phone numbers or email addresses can change,
it is quite rare compared to changes in decision, changes in documents
(incomplete transcripts when they apply, final transcripts at time of
matriculation) or admit conditions (some start out as conditional admits, then
the meet conditions so they become a “regular” admit). 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. [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. 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. [REF] We absolutely need to log it. We’ve used the
existing system for 4 years and have had to tuck these change “logs”
into various notes fields. It is not systematic, searchable or easy to display
back in a student’s record. We are at the tail end of the revamp of our
admissions process and this is one of the key deliverables we have on the
development wish list. 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. [REF] Thanks a lot for your time, Mike! M!ke From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 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 [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] ---------------------------------------------------------- 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] |
- RE: [CFCDev] logging form changes Flynn, Robert E
- RE: [CFCDev] logging form changes Nando
- RE: [CFCDev] logging form changes Dawson, Michael
- Re: [CFCDev] logging form changes Peter J. Farrell
