> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Ben Curtis > Sent: Thursday, January 08, 2004 5:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Best Practices Question: Getters and Setters > > > > > 1) (Like in the onTap Framework) the universal getter/setter first > checks to > > see if a dedicated getter/setter exists (these must be named > > "getPropertyname"/"setPropertyname" for this to work). If one does > work, it > > uses them. > > > > 2) They then checks to see if a special struct, "PropertyDefinition" > exists > > and if the property name is a key in that struct. That struct contains > the > > same information you'd see in CFPARAM (type, default value, etc) and > CFPARAM > > is used to test type (for both output and input). This works because > for a > > getter/setter pair the input and output types will always be the same. > > > > 3) If all of that fails it sets/gets the property "blind". > > > How do you create private vs. public properties in this way? > Douglas mentioned using cfproperty tags to define what > values are gettable, but I assume that means that if a > property is *not* gettable but does exist then the other > functions within the CFC which manipulate the values must do > so directly (foo = "new value") rather than through the > getters/setters. Which sort of defeats the purpose of having > flexible getters and setters, right?
I'm not using CFPROPERTY - but if I were ANY property defined by it would be considered public. In CF you don't declare "public" or "private" - anything in the "this" scope is public - that were my function looks. So if it's in the "this" scope it's fair game. > Can cfproperty accept arbitrary attributes? Would an > "access" attribute (private|public) allow a reasonable > check, and if so, then how does the generic code know > whether the caller is granted access to private properties? It doesn't... nothing's perfect. ;^) As my code is now it only checks the "this" scope (sorta, kinda "public") not the variables scope (sorta, kinda "private"). The more I dig into this the less I like it however... I do LOVE the idea of cleaning up the CFC code (these generic getters/setters would be contained in a toor class all classes would extend, for example, making using them insanely simple). But at the same time I lose the ease of input and output validation and have to add support code to children. I may still do it, but I'm not sure. As for "access" attribute I've done something like that in the past: I've created methods with a "trusted" attribute. If "trusted" was true simpler, less robust code was used which could greatly speed up an application. However this assumes that you know when to make something "trusted" - the component itself loses some important self-protection. But it can be a life saver if you find yourself (as I did) spending CPU cycles doing repetitive validation and conditional logic. I'm going to head down this path for a little while longer... but right now it looks like I'll be sticking with dedicated getters/setters (and the tremendous amount of code that goes with them). I'm still stuck on a simple method for determining a component type if anybody has any ideas... Jim Davis ---------------------------------------------------------- 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]
