Barney, i'm not sure what qualifies as large or small, but i would certainly
find it easier to deploy and especially to maintain if each installation
wasn't different. As that multiplies out, there's a potential headache
there.
I've got about 60 instances out there of our product with 185 cfcs and
counting. Somebody wanted to use it for potentially 1000's of installations,
and i got nervous and kinda backed down over the headaches i foresaw on the
mapping issue. I'd MUCH rather have encapsulated units that i can just
upload to the server(s), maybe at the rate of 5 to 10 a day, and maintain
one codebase, rather than thousands.
It's still possible that it might happen, but unless i can work out this
mapping issue somehow to my satisfaction, i'm holding back pursuing it.
BTW - i was wrong about the typing too. Typing seems to work if the CFC
being instantiated is in the same directory as the Factory, but otherwise
not. So i had to change the returntype to "any" for the Gateways in the dao
directory.
BUT, the composition scheme works fine. I just added the following method to
the Factory, passing in "this":
<cffunction name="getMediaManager" access="public" returntype="MediaManager"
output="no">
<cfset var MediaManager =
createObject('component','MediaManager').init(variables.AppSettings,this) />
<cfreturn MediaManager />
</cffunction>
MediaManager.cfc
<cfcomponent displayname="Media Manager" hint="I help manage media files">
<cffunction name="init" access="public" returntype="MediaManager"
output="no">
<cfargument name="AppSettings" required="Yes"/>
<cfargument name="Factory" required="Yes"/>
<cfset variables.AppSettings = arguments.AppSettings />
<cfset variables.Factory = arguments.Factory />
<cfreturn this />
</cffunction>
.....
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Barney Boisvert
> Sent: Sunday, September 11, 2005 7:36 AM
> To: [email protected]
> Subject: Re: [CFCDev] Factories and mappings
>
>
> You've got one thing backwards, subclasses would need to be at the
> same level or HIGHER than the class they're extending. Other than
> that, it sounds reasonable.
>
> However, there's absolutely no reason that any hosting environment
> (dedicated, shared, mass hosted, whatever) shouldn't give each
> individual website at least one mapping, so I'd say you're better off
> with a build process that'll do a substitution of that mapping at
> install time. So you're code would be say
> extends="${cfcRoot}package.cfc", or whatever, and then at install
> time, you run the build script and it subs out ${cfcRoot} with the
> appropriate value.
>
> I'm also kind of curious. How large of applications are being mass
> hosted like this, and need to have the ability to play nice with
> myriad other apps (both the same code and different)? It seems to me
> that the apps large and complex enough to really benefit from a
> massively OO backend probably aren't the kinds of apps that get
> deployed a bunch of times to shared servers.
>
> cheers,
> barneyb
>
> On 9/10/05, Nando <[EMAIL PROTECTED]> wrote:
> >
> > 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?
> >
> >
>
>
> --
> 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]
