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
