Hal,
thats a pretty good idea and one of the better examples I have seen
where using loose typing is a good alternative.
thanks for sharing.
Bill
On 1/19/06, Hal Helms <[EMAIL PROTECTED]> wrote:
>
> 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]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
