"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: CFCDev@cfczone.org
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: CFCDev@cfczone.org
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: CFCDev@cfczone.org
> 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: 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
>
>





----------------------------------------------------------
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


Reply via email to