To follow up, here's a working example (note the typing works so far)... not
sure what happens when things get more complex, i'd have to work through it
and find out on the way. Anyone see any gotcha's with this approach?
*****
Here's the Factory instantiation, actually after the appliction
configuration object AppSettings is instantiated so it can be passed in ...
ok, i can live with that exception to the "all objects are instantiated with
application.Factory" rule. Maybe i could use Joe's config beans for the
AppSettings objects.
<cfif NOT StructKeyExists(application,"Factory")>
<cflock name="factoryLock" Timeout="10" THROWONTIMEOUT="No"
Type="Exclusive">
<cfif NOT StructKeyExists(application,"Factory")>
<cfset application.Factory =
CreateObject('component','model.TestFactory').init(application.AppSettings)>
</cfif>
</cflock>
</cfif>
TestFactory.cfc in model directory
<cfcomponent>
<cffunction name="init" access="public" returntype="TestFactory"
output="no">
<cfargument name="AppSettings" type="any" required="Yes"/>
<cfset variables.AppSettings = arguments.AppSettings />
<cfset variables.dsn = AppSettings.getDsn() />
<cfreturn this />
</cffunction>
<cffunction name="load" access="public" returntype="any" output="false">
<cfargument name="objectName" required="Yes" type="string" />
<cfset var myInstance = "" />
<cfinvoke
method = "get#arguments.objectName#"
returnVariable = "myInstance" >
<cfreturn myInstance />
</cffunction>
<cffunction name="getImageGateway" access="public"
returntype="dao.ImageGateway" output="no">
<cfset var ImageGateway =
createObject('component','dao.ImageGateway').init(variables.dsn) />
<cfreturn ImageGateway />
</cffunction>
<cffunction name="getTextGateway" access="public"
returntype="dao.TextGateway" output="no">
<cfset var TextGateway =
createObject('component','dao.TextGateway').init(variables.dsn) />
<cfreturn TextGateway />
</cffunction>
<cffunction name="getImageInfo" access="public" returntype="ImageInfo"
output="no">
<cfset var ImageInfo =
createObject('component','ImageInfo').init() />
<cfreturn ImageInfo />
</cffunction>
</cfcomponent>
ps - correction to the below. i had it upsidedown "The only limitation i can
think of is that components that employ an inheritance relationship would
need to be in the same directory or the *parent* would need to be lower."
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Nando
> Sent: Sunday, September 11, 2005 7:08 AM
> To: [email protected]
> Subject: [CFCDev] Factories and mappings
>
>
>
> Kerry's post about using a GatewayFactory got me thinking about
> factories in
> general, and i wanted to float an idea out here and see what some of you
> smarter, more experienced OO'ers think.
>
> One of the practical problems some of us run across in using CFC's rather
> intensively in our distributed apps, one's we're building to sell multiple
> times, is that mappings cannot be set on an individual application - they
> are server wide. So to have more than one instance of an app on a server
> puts you through some gymnastics. Either you have to search and
> replace the
> mapping name in your CFC's and test each individual app carefully for any
> errors (and carefully maintain all those variations!), or you need to put
> them in separate server instances ... or you just can't use
> mappings, which
> tends to tie you down.
>
> Now let's say that we design our app as Kerry suggests, so that on
> application start, a Factory is instantiated into application scope from
> Application.cfc or Application.cfm. All object instances in the
> application
> are created by Factory (or it's composed child Factory classes if you want
> to break the responsibilities up, as you probably should).
>
> Now, as long as your CFC's are in the same directory as Factory or lower,
> the singleton instance of application.Factory should have no
> problem finding
> them, instantiating them, and returning them without a mapping. Going down
> the directory tree works, it's just going up where you run into problems.
> The only limitation i can think of is that components that employ an
> inheritance relationship would need to be in the same directory
> or the child
> would need to be lower. Composition, no matter how the objects are in
> relation to each other, could be handled by application.Factory
> (you'd pass
> in a reference of application.Factory, actually you'd pass in "this" when
> instantiating parent components and use Factory to instantiate the
> children).
>
> Anyone see any holes or limitations one would run across down the
> line with
> this approach?
>
>
>
>
>
>
> ----------------------------------------------------------
> 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]
