I'd like to give the "thumbs-down" on CFSqlTool. It's author consistently makes incoherent arguments (on this list) about why it's acceptable that his tool violate "best practice". Usage of the this scope for instance data, generic get/setProperty methods, and variable names with "$" in them all add up to great reasons NOT to use this tool, and I would stay away from any project that used or planned on using it.
With all that said, maybe someone should become a committer and *fix* those problems so warnings like this don't have to be posted. -Dave >>> [EMAIL PROTECTED] 10/27/05 10:50 AM >>> Phillip, Have you all looked at http://cfopen.org/projects/cfsqltool/ You might want to become a submitter on this project. Thanks, Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Senn Sent: Thursday, October 27, 2005 10:39 AM To: [email protected] Subject: RE: [CFCDev] CFCs and OOP - How to handle this? Mike, I too am in the process of developing a generic CRUD application. Here's its premise: 1. All database CRUD goes through stored procedures (<cfquery> not allowed). 2. The stored procedures have security. 3. The stored procedures provide logging. I'd like to compare notes with you. I posted some code to a Google group on Sep 2, 2005. http://groups.google.com/group/CF_COAL/browse_thread/thread/fd002480f207 360c But didn't find any takers on developing the idea further. I'd like to make it robust. _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Kear Sent: Thursday, October 27, 2005 1:38 AM To: [email protected] Subject: [CFCDev] CFCs and OOP - How to handle this? I'm feeling pretty proud of myself right now, because I got round to writing a small test app using a CFCBean and CFCCRUD, without a safety net, without looking at other people's examples, without referring to my own previous work. In other words, I proved to myself I can write a OOP app all by myself, thereby getting myself past a milestone in this learning process. The app itself doesn't do much - just takes two fields, lets the user modify them as many times as he likes, updating the bean each time, then when the user clicks "commit", it saves the data to a SQLServer table. This is something I've seen many times before in more complex sites, particularly when there is a 'wizard' style multi-page form. So here's my question: In the process, I've realised there is a potential problem with this style of user interaction - since the user is going from page to page without actually saving the data to the database, there is a risk they could get to the end of the process, and THINK they've saved all the info, and then quit and go somewhere else, never having saved their info. How do you all handle such a problem? Or do you just avoid this scenario altogether and save each step to the database (or other persistent storage) as the user goes from step to step? Anyway, I'm sitting here, pretty happy that I was able ot create a bean, populate it with values from both user interaction via a form, and from persistent storage via a CRUD and SQLServer database,, then manipulate the values, use them in output, and save the final version back to the database. Whoohoo!!! You dont need to congratulate me, I'm doing enough of that by myself. <g> -- Cheers Mike Kear Windsor, NSW, Australia Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month ---------------------------------------------------------- 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] ---------------------------------------------------------- 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] ----------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited. To contact Albany Medical Center, or for a copy of our privacy practices, please visit us on the Internet at www.amc.edu. ---------------------------------------------------------- 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]
