Title: Message
Yeah, that guy...
 
;-)
 
Having finally realized the futility of pseudo-static typing in CF has opened up a bunch of possibilities. For example, in my Jan. 27 newsletter, I'm going to be showing how to do mixins by adding two methods to a BaseComponent.cfc, which takes the place (for me) of the WEB-INF/cftags/component.cfc. (Although I could add these directly into the component.cfc, I prefer to have a separate component for portability.)
 
Anyway, since I already have a BaseComponent that I've put things like an objectID, the mixin methods, and several other things, it occurred to me: 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.
 
The standard implementation of these should work 95% of the time, but what about the occasion when I need a getter that does more than <cfreturn variables.instance[arguments.propertyName] />? For that, I check within my universal get method whether an actual getX method exists (where X = arguments.propertyName). If so, my get method calls that instead of using its standard code. I do the same for the universal set method.
 
That means that if I have no special getter for, say, a name property of an object, this code works:
<cfset yourName = you.get('name') />
 
But if you happen to have a special getName method, that same code still works.
 
There's a lot of power in ColdFusion when we don't treat it like Java Lite.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Israel-Davis
Sent: Thursday, January 19, 2006 5:08 PM
To: [email protected]
Subject: RE: [CFCDev] Bean and CFC question

 

Also the file > new > other > CFC dialogue in CFEclipse perspective will create getters and setters.  It also will add empty methods with arguments that you specify.  It’s pretty nifty.

 

My only gripe is that the return or argument type can’t be a string of my choosing.  For objects, I default to “any” and change them when I write the method code.

 

Of course now Hal Helms is arguing against strong typing in CF (see the latest CFDJ - http://coldfusion.sys-con.com/read/167973.htm ) I’ll be curious to see part 2 of the article next month.  Just when you think something’s a best practice…maybe it isn’t…or is…or might be…sometimes. It depends.

 

anthony

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raphael Gerber (codeyard)
Sent: Thursday, January 19, 2006 1:31 PM
To: [email protected]
Subject: RE: [CFCDev] Bean and CFC question

 

I'm tired of writing Setters and Getters all the time as well. That's why I added the following snippet to Eclipse/Homesite:

 

 <cffunction name="set$${Name}" returntype="void" access="$${Access:private|public}" output="false"
  hint="I set the $${Variable} property.">
  <cfargument name="$${Variable}" type="$${Type:any|array|binary|boolean|date|guid|numeric|query|string|struct|uuid|xml}" required="true" />
  <cfset variables.instance.$${Variable} = arguments.$${Variable} />
 </cffunction>

 

 <cffunction name="get$${Name}" returntype="$${Type:any|array|binary|boolean|date|guid|numeric|query|string|struct|uuid|xml}" access="public" output="false"
  hint="I get the $${Variable} property.">
  <cfreturn variables.instance.$${Variable} />
 </cffunction>

 

Raphael Gerber

--
codeyard web development
http://www.codeyard.ch 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Han
Sent: Thursday, January 19, 2006 10:16 PM
To: [email protected]
Subject: [CFCDev] Bean and CFC question

I like the use of beans as a bridge to transport data between the presentation layer (forms) and business objects, which do all the database interactions.  Constructing beans can be a repetitive and time-consuming task, so lately I have been toying around with a different transfer object that acts like a bean, but it is easier to build, add on, and maintain.  I would like your opinions on it and whether it is a good or bad.

 

Instead of writing a bean that has getters and setters and will interface like this:

 

 

<cfset objFilter=CreateObject(“component”,”reportFilter”).init(dsn)>

 

Method #1

 

<cfset objFilter.setFirstname=”John”>

<cfset objFilter.setLastName=”Doe”>

 

I then pass this objFilter into my business object.  Inside the business object, the values in the filter object will be accessed like this:

 

Arguments.objFilter.getFirstName();

Arguments.objFilter.getLastName();

 

Method #2

 

I have been toying with this method:

 

<cfset objFilter.add('firstname','John')>

<cfset objFilter.add('lastname','Doe')>

 

Inside my business object, I would access the values of the objFilter like this:

 

Arguments.objFilter.getValue('lastName')

Arguments.objFilter.getValue('firstname')

 

The advantage I see in Method 2 is that as the business object requires additional filter parameters, the objFilter object doesn't require the maintenance of adding more getters or setters.

 

Any thought on the good or bad on Method #2 is appreciated.  Thanks.

 

 

----------------------------------------------------------
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] ----------------------------------------------------------
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]

Reply via email to