I've been doing the same thing for some time, but I do generate some
restrictions by identifying all the properties of bean by using the
<CFPROPERTY> tag. Here is a typical line:
<cfproperty name="ASSESSMENTID" type="CF_SQL_NUMERIC"
required="TRUE" metadata="false" hint="FK (tblAssessment) I am the
assessment cycle for which this from was filled out. Assessment number
will be reported out as ASSESSMENTNUMBER or ASSNUM. Other data available
in look up table and beyond to tblPatient. " />
When I instantiate, I set up all sorts of metadata that identify the
property and even some validation. I have generic setters and getters,
but if the property doesn't exist then it throws a friendly error that
identifies the name of the cfc and the name of the property.
One other aside. If you notice the typing that I use. These are always
the types that you can use in a CFQUERYPARAM. I use this in the save
method of my dao to build the insert and update statements on the fly.
I enter all the description into my table (note that the hint is pulled
directly from the comments attribute directly in the database). So I
can use my own code generation tool to create all the cfproperty tags.
-----------------------------------
Gerry Gurevich
Application Development
NIEHS ITSS Contractor
Lockheed Martin Information Technology
919-361-5444 ext 311
-----Original Message-----
From: Joe Rinehart [mailto:[EMAIL PROTECTED]
Sent: Friday, January 20, 2006 8:29 AM
To: [email protected]
Subject: Re: [CFCDev] Bean and CFC question
> > why am I writing separate getters and setters when I no longer am
concerned
> > about pseudo-static typing? So, I wrote universal get(propertyName)
and
> > set(propertyName, value) methods for BaseComponent.cfc.
>
> My initial reaction was "yuck!" until I saw your caveat about
> detecting and calling getX() if it is defined. That's pretty sweet.
Ugh, I'm still against it. It allows (at least a portion of) your
CFC's private scope to be manipulated directly, essentially tossing
out the whole of data hiding.
For instance, say I had the following CFC:
<cfcomponent>
<cffunction name="set">
<cfargument name="name" />
<cfargument name="value" />
<cfset variables[arguments.name] = arguments.value />
</cffunction>
<cffunction name="get">
<cfargument name="name" />
<cfreturn variables[arguments.name] />
</cffunction>
<cffunction name="blowUpEarth" access="private">
<cfoutput>Earth go boom!</cfoutput>
</cffunction>
<cffunction name="createInterstellarBypass">
<cfset blowUpEarth() />
<cfreturn "Obstacles cleared." />
</cffunction>
</cfcomponent>
And then I run this code:
<cfset tmp = createObject("component", "temp") />
<cfdump var="#tmp.createInterstellarBypass()#" />
<cfset tmp.set("blowUpEarth", "BOOM!") />
<cfdump var="#tmp.createInterstellarBypass()#" />
My first call to createInterstallerBypass() will work, but the second
will fail. The only thing to blame is that the API's consumer didn't
know that there was a private method named "blowUpEarth" - but wait,
how can we blame an API user for not knowing the details of the
implementation?
Sure, we can "protect" things by limiting the generic set() to only
alter something like a variables._unsafe structure, but either way we
slice it, the consumer is setting unchecked values into a private
scope, and we're adding unneeded implementation complexity for no
reason I can see other than not wanting to take the five minutes to
write get/set methods.
Being able to dynamically type things is pretty powerful, but I'm
afraid we're going to start taking it to extemes where it becomes
impractical. Like all things, I think there's a balance point: I've
used type="any" for a long time for many things, but I've also used
type="be.what.i.need.you.to.be" in places where it's called for.
--
Get Glued!
The Model-Glue ColdFusion Framework
http://www.model-glue.com
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of
the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.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' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
