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.instance.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: CFCDev@cfczone.org
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: CFCDev@cfczone.org
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
cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org
