What about splitting it into 2 parts? 1. Have the Facility CFC provide a generic getter/setter so the CFC isn't cluttered
2. If you're validating against general things (such as "is this a valid date, or zip code?"), do those REALLY have to be part of the CFC at all? Can they live in a separate library of UDFs or in another Validation CFC that is inherited? Since you have data coming in from a form post as well as an importing routine, it's feasible that you may want an instance of just the "validation" CFC at different locations than just inside the Facility CFC, yes? Or am I way off here? -----Original Message----- From: Dawson, Michael [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 10:31 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Best Practices Question: Getters and Setters Personally, I would keep the setters/getters separate as much as possible. I initially thought you could have a generice setter and getter and specify the variable name to be set or retrieved. Then, after a bit more thinking, "what if I want to add a specific validation routine to only one variable". Maybe your idea of "grouped" setters/getters is good. What if you had separate setters, but one getter that returned a query object or a structure that contained all variables? I do something similar in that I create a component structure variable named "Instance". In my Init() method, I assign all variables as children of this structure. I can then use <cfreturn Instance.FirstName> for granular control or I can use <cfreturn Instance> to get the whole kit and kaboodle. M!ke Dawson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ousterhout Sent: Wednesday, January 07, 2004 12:06 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Best Practices Question: Getters and Setters I create some logical groups. For example, I have one getter/setter for address. Same for items on an order/invoice. Don't know if it is a best practice, just seemed to make the code more readable. I started with individual ones and everything got more complicated. Andy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 11:22 AM To: [EMAIL PROTECTED] Subject: [CFCDev] Best Practices Question: Getters and Setters I have a CFC with 26 properties. None are inherited. I find that having 52 methods for getting and setting to be a bit cumbersome to keep in my CFC with the "real" methods. I was thinking of including all my getters and setters from a CF template. Let's say that the my code looks like this: facility.cfc <cfcomponent hint="I am a facility"> <!--- Include the getters and setters ---> <cfinclude template= "facilitygetset.cfm"> <!--- Start the more complicated stuff ---> <cffunction name="firstrealmethod"> . . . </cffunction> . . . . </cfcomponent> Any thoughts on this as a good idea, bad idea, unintended consequences? ------------------------------------------------ Gerry Gurevich, Lockheed Martin [EMAIL PROTECTED] 919-572-7818 ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
