This falls under the "black box" concept, in that the component isn't supposed to know about the environement is getting used in. We don't care if some arbitrary code changes the properties. However, we do care about having valid data before it is placed into the database. So, our components (data access components at least) have an isValid() function which is public, and is also called internally when a save is done.
When I first started exploring components in detail (all of 3 weeks ago), this was the first issue we ran into - you can't really type cast your properties, then enforce that type casting (at least not when using a CFC as a component - I understand this may be different when used as a web service). We were initially going to create get and set methods for member variables (not in the THIS scope), but quickly realized this was meaningless, because I was free to set variables on the object willy-nilly. For example, a component might have two official properties - say "x" and "y". I can freely create my own properties by assigning a value to them (like javascript)... : <cfscript> oPos = createObject("component", "myposition"); oPos.x = 5; oPos.y = 6; oPos.z = 15; //This is not an officially supported property oPos.MyOwnProperty = "Hi ya Bob"; //another "unofficial" property </cfscript> If you do a cfdump of the oPos object, it DOES reflect the two additional properties, even though they were not defined in the CFC. So, doing get's and set's to enforce data type becomes meaningless - instead of saying oObj.getProperty(); a user could do oObj.Property = 1;, and x = oObj.Property;, bypassing the functions. We decided it was easiest to simply validate the properties before saves, and allow the calling code to call the isValid method as well. k, I've rambled on long enough... hope this helps someone out there. Shawn -----Original Message----- From: Sean A Corfield [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 5:30 PM To: CF-Talk Subject: Re: Help with CFC and recursion? On Tuesday, May 27, 2003, at 16:20 US/Pacific, Shawn Grover wrote: > We're declaring a Clear function which initializes the THIS properties > to a > valid, known state. Our procedure is to ensure the clear function > matches > the CFPROPERTY declarations, and we call the Clear function when the > CFC is > initialized. And what's to stop some arbitrary method just setting this.foo to some value? (or, worse, some client code that instantiates a CFC and then sets the public data) foo.cfc: <cfcomponent> <cfproperty name="bar" type="numeric"/> <cffunction name="clear"> <cfset this.bar = 0/> </cffunction> ... </cfcomponent> bogus.cfm: <cfset foo = createObject("component","foo")/> <cfset foo.clear()/> <cfset foo.bar = "Hah! I'm a STRING now!"/> Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4