Nando, Is this concept a thought of multiple applications running together? If I buy several apps built like this... would they all have to be working from the application.cfc file? It seems like that would be an issue. The site calendar, site forum, site shop would all have their own application.cfc and the issue would be there would not be a common site API. This is one of the things that seems to be missing IMHO. When I purchase different applications to run on one site I want them to share common site API and then to have individual application settings. It seems in the thrust to make sure we are OO that we forget/neglect this goal. Is there a way to get your factory type thing to resolve this kind of issue?
Thanks, John Farrar -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Sunday, September 11, 2005 1: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]
