I really like the idea of a config object, but I'm having trouble picturing it. Could you give me a simple idea of what it looks like? And how it is used in code - I don't need anything fancy, just a general idea of what kind of methods are contained in it (if anything beyond init?) It sounds like it just sets a bunch of variables, which makes sense to me - is there anything else to it?
Thanks! Anthony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Friday, September 09, 2005 1:24 PM To: [email protected] Subject: Re: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? Just for reference, I also use a factory to create all my gateways. The factory gets created with a reference to my app config object, and then it takes care of passing the dsn from that into the constructor of the gateways when it constructs them, and caches them for subsequent requests. It also handles "special" gateways like for uploaded files, where you need a directory reference as well as a dsn, so the application doesn't need to care what args the given gateway needs. If you ask me, this is really the utmost of laziness, because I can change the init params of all my "normal" gateways in a single line of code, and if I need to change some "weird" gateways as well, they're right there in the same file. Since everything goes through the factory, I'm guarenteed that my app won't break in any way, no matter how drastic the changes. cheers, barneyb On 9/9/05, Jason Davey <[EMAIL PROTECTED]> wrote: > > 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. > -- 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]
