Kerry: I want to answer your question "hows that?" properly but I need time to play with these techniques.
Thank you for taking the time to provide an example. I'll be back at ya next week. Have a great weekend, all. Jason D. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kerry Sent: Friday, September 09, 2005 12:18 PM To: [email protected] Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? <cfquery name="test" datasource="#THIS.dsn#" You gotta be kidding me! after going to all that effort with singletons, factories and encapsulation, we're not going to use #this#, at any point in time, ever! well, maybe sometimes, but not this time :) Sorry to repeat, but, just to re-cap: config.cfc (singleton, created on app start) gatewayfactory.cfc (singleton, created on app start, inited with config.cfc) gateway factory creates each gateway, and in turn, inits them with the config.cfc reference so now lets take a look at the employee gateway example.... objEmpGW = application.gatewayFactory.load("employee"); (side note, a pointer to this could be placed in the request scope by a global file, e.g. application.cfm, so it could be request.gwFactry.load("employee")) function load(gatewayname){ return createobject("component","path.to.mygateways."&arguments.gatewayname).init(c onfig=variables.inst.obj.config) ; } employeegateway.cfc function init(config){ variables.inst.obj.config = arguments.config; } function getEmployees(){ <cfquery name="test" datasource="#variables.inst.obj.config.getDsn()#" } hows that? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Davey Sent: 09 September 2005 16:52 To: [email protected] Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? Kerry: I see your approach more clearly. I like the singleton instance idea via a gateway factory and avoiding using the CreateObject() function every time you invoke a component - that seems to make complete perfomance sense. So in effect you scope your component in an application variable once (on app startup) and then use that component instance every time you need an application variable value such as dsn? To finish off the logic, can you provide an example of how a <cfquery..datasource="?" attribute looks like using this factory method? Using the getEmployees() method call below (from previous posts). I suspect it would be something like <cfquery name="test" datasource="#THIS.dsn#"... Thanks. Jason D. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kerry Sent: Friday, September 09, 2005 11:22 AM To: [email protected] Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? "I would prefer not to have to remember to write this line when instantiating a Gateway object" oh, I think I see what you mean, you want to directly create the component yourself like this: objGW = CreateObject("component","someObjGW").init(); well, I have to say that I rarely use createobject in a .cfm file, as every component is created from singleton factories. Im not sure what the fuss is about remembering though. factories are invaluable, especially when in the future you decide you want to refactor your app, with a singleton factory, you dont have to find every instance of CreateObject("component","... in all your cfms, you simply change the way the factory creates the object, and you're all done. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Davey Sent: 09 September 2005 15:45 To: [email protected] Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? Kerry: I credit this approach by abstracting the dsn setting to a gateway cfc. My goal is to make the interface as simple and as possible for the caller to retrieve records following the idea that other programmers will want to interface your components. I would prefer not to have to remember to write this line when instantiating a Gateway object: "objGW = application.gatewayfactory.load("someObjGW");" unless you do what I propose below which is to embed this call within a GW component (then you don't have to remember it!). The approach I thought about does not require the caller to pass in a datasource argument - instead the datasource becomes a private property of the gateway component. However, this approach breaks encapsulation because the component method relies on another component called "systemGW" and method "getDataSource(), BUT, on balance (and that phrase is key in deciding the solution), because we are dealing with APPLICATION scope variables, they are more constant and therefore we can arguably get away with breaking the pattern. So... In the init method you have: <cfscript> setDataSource(); return THIS; </cfscript> Modify the original setDataSource() method to call a systemGW object that in turn gets the datasource value from an INI, registry or database setting ... Use this method for all setting of datasources. <cffunction name="setDataSource" access="private" returntype="void" output="false"> <cfscript> objSystemGW = CreateObject("component",".systemGW"); VARIABLES.datasource = objSystemGW.getDataSource(); </cfscript> </cffunction> In the calling page you only need... objGW.getEmployees(); Thus making the interface very simple. Jason D. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Friday, September 09, 2005 4:30 AM To: [email protected] Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use the THIS scope for a ColdFusion Component? Kerry, Hmmm, an all purpose factory. Do you handle it in some way if the CFC doesn't exist? What about type checking? I'm wondering if it would be better to call a getter with the load function and if the getter doesn't exist, return an error. I like the single load function tho'. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Kerry > Sent: Friday, September 09, 2005 10:08 AM > To: [email protected] > Subject: RE: [CFCDev] Method parameters vs method names WAS: When to > use the THIS scope for a ColdFusion Component? > > > My Answer: > > gatewayFactory.cfc > > function init(dsn,someargs){ > variables.instance.dsn = arguments.dsn; > variables.instance.something = arguments.somethingelse; } > > function load(gatewayname){ > return > createobject("component",arguments.gatewayname).init(variables.ins > tance.dsn) > ; > } > > > > on application start > > application.gatewayfactory = > createobject("component","gatewayFactory").init(mydsn,myothervariables > ); > > > > in page: > > objGW = application.gatewayfactory.load("someObjGW"); > objGW.getEmployees(); > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Jason Davey > Sent: 09 September 2005 08:58 > To: [email protected] > Subject: RE: [CFCDev] Method parameters vs method names WAS: When to > use the THIS scope for a ColdFusion Component? > > > Barney: > > I like the idea of creating methods with no parameters e.g. > getGasRemaining() thereby abstracting the interface from the caller. > This raises the following question. In the case where you are calling > a Gateway method (SQL SELECT calls), how do you create a clean method e.g. > getEmployees() without passing in a datasource parameter? E.g. > objGateway.getEmployees(APPLICATION.DataSource) > > My answer: the gateway component itself has a property called > "datasource"? > Therefore, would the following be the right approach? > > objGW = CreateObject("component","someObjGW").init(); > objGW.datasource = APPLICATION.DataSource; objGW.getEmployees(); > > Inside the Gateway component, there is the following: > > The component 'setter / getter' functions... > > <!--- set ---> > <cffunction name="setDataSource" access="private" returntype="void" > output="false"> > > <cfargument name="datasource" type="string" required="true" /> <cfset > variables.datasource = ARGUMENTS.datasource /> </cffunction> > > <!--- get ---> > <cffunction name="getDataSource" access="private" returntype="string" > output="false"> > <cfreturn variables.datasource /> > </cffunction> > > > And then the getEmployees function... > > <cffunction > name="getEmployees" > access="public" > returntype="query" > displayname="" > hint="returns a list of all employees" > output="false"> > > > > <cfquery name="qryGetEmployees" > datasource="#THIS.datasource#"> > > SELECT * > FROM people where category = 'employee' > > </cfquery> > > > <cfreturn qryGetEmployees /> > </cffunction> > > Jason D > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Barney Boisvert > Sent: Tuesday, August 30, 2005 4:12 PM > To: [email protected] > Subject: Re: [CFCDev] Method parameters vs method names WAS: When to > use the THIS scope for a ColdFusion Component? > > Yes, because that changes the interface, which will break existing code. > You could make it an OPTIONAL parameter that defaults to 'gallons', > and be safe, but I don't like the idea of passing in parameters that > dictate behaviour to methods. I much prefer to have a distinct method > for each distinct behaviour, if that makes sense. > > To take a different tact, the standard definition of a getter is a > "Zero argument method that returns the value of an object's property", > not a "one argument method that returns the value of an object's > property, based on some dynamic calulation that relies on the passed > argument". So, you no longer really have a vanilla getter. Note, > however, that neither definition precludes you from doing some wholly > internal computation to arive at the returned value; it's the external > dependancy (the passed parameter) that differentiates them. > > Subtle points, but enough to make me take the "add methods" route. > > cheers, > barneyb > > On 8/30/05, John Ottenbacher <[EMAIL PROTECTED]> wrote: > > Greetings, > > > > I am trying to transition from procedural development to OO development. > > > > I'm curious, in the example given is there anything 'wrong' with > > adding a parameter to GetGasLeft()? It would have to be optional > > and default to the original unit of measurement so as not to break > > existing > code. > > > > getGasLeft("GALLONS") > > getGasLeft("METERS") > > > > Thanks, > > > > John > > > > -- > 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] > > > > > > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
