So far, simply is enough. But tomorrow that may of course change. Joe's got a good article on his implementation of the Abstract Factory on his blog, and why he did it that way. I was also rereading his stuff on factories today. There are some code samples in there to take a look at.
http://clearsoftware.net/client/index.cfm?mode=entry&entry=89F69AD3-E081-2BA C-695BECE0066A7203 ciao, Nando >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Salvatore Fusto >Sent: Tuesday, November 15, 2005 4:41 PM >To: [email protected] >Subject: Re: [CFCDev] SQL datasource within CFC > > >ciao nando, >i'd be interested in your, and all, code sample: do you implement the >abstract factory pattern as described in J2EE or do you use a more >simplified way? >regards >salvatore >----- Original Message ----- >From: "Nando" <[EMAIL PROTECTED]> >To: <[email protected]> >Sent: Tuesday, November 15, 2005 4:14 PM >Subject: RE: [CFCDev] SQL datasource within CFC > > >> What i'd do is use a Factory to instantiate my CFC's. That gives you the >> opportunity to pass your datasource in as Patrick suggests very >easily. If >> you need a code sample, give a shout. There are lots in the archive, but >> they may be difficult to find. >> >> ciao, >> Nando >> >>>-----Original Message----- >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>Behalf Of Geoff Parkhurst >>>Sent: Tuesday, November 15, 2005 3:16 PM >>>To: [email protected] >>>Subject: [CFCDev] SQL datasource within CFC >>> >>> >>>Afternoon all. >>> >>>Hoping someone can help... I'm a bit confused about using sql datasources >>>within CFCs, and was wondering if there's a de-facto "right" way >to do it. >>> >>>1. Pet Market sets a request variable on every page view >(Application.cfm: >>><cfset request.petmarketdb = "petmarket">), which is dumped into the >>>'this' >>>scope of any CFC when an instance is created (user.cfc: <cfset this.db = >>>request.petmarketdb>). - Perhaps the 'variables' scope would be better >>>than >>>'this'? Also feels 'bad' to me - shouldn't the CFC be totally >independent? >>> >>>2. >http://www.macromedia.com/devnet/coldfusion/articles/cfc_practices.html >>>this article just names the datasources directly itself throughout the >>>CFC. >>>- Not very portable. >>> >>>3. http://www.sitepoint.com/print/components-introduction this article >>>just >>>directly uses the #application.datasource#. - Again, feels 'bad' to me, >>>though convenient... >>> >>>Currently, my non-cfc code just uses #application.ds# as a datasource for >>>all queries. So, my guess would be I need to pass this application >>>variable >>>to every CFC I create? >>> >>>Or should I stop whingeing and just use my application variable directly? >>> >>>Any thoughts would be much appreciated; I'm trying to avoid any bad >>>habits... Sorry if this is a bit basic, but I've just read the >>>"who owns the >>>ID?" thread and managed to confuse myself... >>> >>>Cheers, >>>Geoff >>> >>>Ps. Couple of snippets below - I can't see how the cfquery gets to >>>know what >>>its datasource should be.... Maybe <cfset >>>variables.datasource=application.datasource> in the init() >>>function? Or just >>>read the application.datasource variable directly? >>> >>>Application.cfc: >>><cffunction name="onapplicationstart"> >>> <cfset application.datasource="something"> >>> <cfreturn true> >>></cffunction> >>> >>><cffunction name="onsessionstart" returnType="void" output="false"> >>> <cfset session.user=createobject("component", "user").init()> >>></cffunction> >>> >>>User.cfc: >>> >>><cffunction name="init" access="public" output="false" >>>returntype="struct"> >>> <cfset variables.user=structnew()> >>> <cfset variables.user.email=""> >>> <cfset variables.user.password=""> >>></cffunction> >>> >>><cffunction name="login" access="public" returntype="boolean" >>>output="false"> >>> <cfargument name="email" required="true" type="string"> >>> <cfargument name="password" required="true" type="string"> >>> <cfset var status = false> >>> <cfset var finduser=""> >>> <cfquery name="finduser" datasource="iamnotsure"> >>> select userid >>> from users >>> where email = '#trim(arguments.email)#' >>> and password = '#trim(arguments.password)#' >>> </cfquery> >>> <cfif finduser.recordcount> >>> <cfset status = true> >>> </cfif> >>> <cfreturn status> >>></cffunction> >>> >>> >>> >>> >>>---------------------------------------------------------- >>>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). >>> >>>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). >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> >> >> >> __________ Informazione NOD32 1.1286 (20051115) __________ >> >> Questo messaggio รจ stato controllato dal Sistema Antivirus NOD32 >> http://www.nod32.it >> >> > > > >---------------------------------------------------------- >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). > >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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
