- Ken
On Jul 12, 2004, at 3:40 PM, Barney Boisvert wrote:
I started down the same route, and it works pretty well. I opted to throw
exceptions if you get or set an invalid property, but it generally works
quite well.
However, once I built a tool that will auto-generate my CFCs for me based on
a schema (currently read from the DB, though it could come from anywhere),
building all those getters and setters was irrelevant, because I just let CF
do it for me.
If mindless repetition of code is the stumbling block for actually using
beans, that's something that can definitely be beaten by the computer.
Sure, it requires a little development that appears "non-productive", but it
really is worth it.
Cheers, barneyb
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Dunnington Sent: Monday, July 12, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: [CFCDev] Beans: Explicit vs Implicit arguments?
I am trying to get into Mach-ii and just read Ben Edwards' article about using Beans. I have been using for some time a method of data encapsulation that relies on implicit arguments. In my CFC I declare an instance struct within the variables scope - nothing new there. Then I have two functions, get(string varName) and set(string varName, string varValue) which search the instance scope for the variable requested. If it does not exist, get returns an empty string, while set creates the variable and assigns it the given value. This has worked well for rapid application development (I am the only CF/database developer at my company, so I develop application code alongside developing database schemas.) but I know it's not really a best practice. My question is, what is the general consensus concerning the use of beans, with their strict rules of getters and setters, and what are people's thoughts on my method? It has definitely saved me time, with only a few small caveats (dealing with undefined numeric values, for example.)
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
