Nando, It was just pseudo code, written off the top of my head, and with only just enough code to demonstrate the functionality. I dont know if I would call it "all purpose", as from the name, its a gateway factory only. Regarding additional functionality, I might have it do things like keep the created gateways in its variables scope, so that they are all singletons. Regarding errors, I would just let cf throw its own component not found error! Regarding type checking, whats to type? The object name is a string, the gateway factory could be in the gateway folder, and you could ensure that there are no "." in the passed argument name, so that the factory can only create gateways from its own folder, so you would kind of have packaging enforcing the typing. Or you could init it with a list of object names that its allowed to create? Just a few thoughts there, nothing i've really thought through....
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nando Sent: 09 September 2005 09:30 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]
