Barney: I'm now on the fence about these different approaches. Again I keep going back to the phrase, "on balance" to determine if a solution is right. Meaning that "foolish waste of resources" is relative tradeoff between coding practices and resource efficiency. I'm interested in code that minimizes complexity of interface calls because I'm lazy and I forget 3 months down the road how to get something from an object. This is why I liked your position of clean methods that don't pass parameters. The "getEmployees()" method was the starting point this morning. And then I wanted to stream-line it further by avoiding having the caller set datasource as a property of the object as in "objGW.datasource=dsn;". The getDataSource() method embedded in the setter seemed like a reasonable approach. But the good feedback today has given us other options to think about.
Along came Kerry with the factory approach which pulls in the "raw" variable from the application scope instance. I like this approach and want to play with it further because it seems to me to provide better resource efficiency lacking in the getDataSource() - invoke another CFC method - while allowing the raw variable to be planted in the setter function as per your suggestion. In short, I'm looking for the best way to call a gateway and not have to pass in a datasource parameter so I can continue to be lazy, forgetful and worry free. Jason D. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Friday, September 09, 2005 2:49 PM To: [email protected] Subject: Re: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? I guess my point was that I am explicitly disallow considering the datasource to be a property of the gateway object. It's an implementation detail that the gateway object doesn't claim to know anything about. If you wanted to use a setter (which is probably reasonable), you can do that and make it a private method so that people can't use it. You maintain the abstracted setting of the variable, but also retain the datasource's status as non-property, since no one except the CFC itself can do anything with it. However, if you do that, then you'll want to use getDatasource() in all your CFQUERY tags, rather than the raw variable, and to me, that's a foolish waste of resources, and the main reason I don't do it that way. cheers, barneyb On 9/9/05, Jason Davey <[EMAIL PROTECTED]> wrote: > Barney: Thank you for confirming my thoughts. > > I prefer the getter / setter methods so that I can optionally and > deliberately break OO patterns where I want to embed logic in the > setter method that is more than just <cfset variables.dsn = > arguments.dsn>. See my previous post for an example. > > In fact, as far as syntax goes, I like this in my init() method: > > <cfscript> > setDataSource(); > return THIS; > </cfscript> > > Jason D. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
