Having that "committed" flag is a good idea because it allows you to later clear out "stale" data. That is, you might want to later write a DB cleanup routine that cycles through the DB and cleans out all "uncommitted" data that is more than X days old, or some other suitable time-frame.
/cody -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Wednesday, October 26, 2005 9:38 AM To: [email protected] Subject: Re: [CFCDev] Making changes before a commit button I'd commit the data to the database as soon as the form is submitted, flagging it as "uncommitted" or whatever. Then when they hit the 'commit' button, you just clear that flag. That way there's no potential for data loss, even if the user's browser crashes, or they get called away on the phone and their session times out or whatever. They can log back in, and pull back up whatever they were working on. cheers, barneyb On 10/26/05, Mike Kear <[EMAIL PROTECTED]> wrote: > I'm feeling pretty proud of my self today - for the first time, I > wrote, unaided, with no safety net, a small app, which uses a CFC Bean to handle > the variables in the object, then a CRUD.cfc to insert the details to a > SQLServer table. This app doesnt do much worth anything, except prove to > me that I have learned enough that I can write using this OOP method, > without copying off other people's stuff. This is a MAJOR milestone for > me! > > Anyway, the way this app works is that a user is presented a form, > can make all the changes and tweaks he wants to the details before finally committing > the details to the database. The bean cfc contains all the data while the > user tinkers around with it, then passes it to the CRUD.cfc when the > time comes to commit the data to the database. > > So here's a potential problem I haven't put a lot of thought into > before, but must have been dealt with by others, and now i realise > it's really vital to solve: > > [Q] How do you ensure that the user clicks the "commit" button before > leaving the application? There would be a risk I'd have thought, that the > user can complete the forms, tinker around with the data getting it > right, thinking it's been added to the database, but it really hasnt. It's still > in the bean cfc waiting for the user to commit it. (If it was a simple > form, i would make the submit button commit the data to the database > right then and there, but the kind of app I'm thinking of using this > process is where there is quite complex interrelated data to deal with > - such as a page definition in a CMS or multi-stage wizard form where > the data required in one part depends on what was supplied to another. > ) > > > I know I've seen these kinds of apps before, but never thought much > about what was going on in the background before. > > > > Cheers > Mike Kear -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
