We use a mapping on one of our products, but the components that are in this mapped directory really are generic across all instances of the application on the server. This enables us to have n instances of the app running but only one primary codebase.
Furthermore due to the nature of the application if one customer wants a customization to the core functionality it is just analyzed and then, if appropriate, added as a new function that affects all customers, not just the requestor. Otherwise, due to the plugin nature of the application, if we can support their request via a plugin, then we do that. This lets every customer have access to the functionality if they want it - but only those that do have to deal with it. Overall, it works pretty well - and provides us with a great amount of flexibility. Sadly, we can't use a similar architecture for every application - but most of our stuff is custom solutions for a particular customer. We only sell one "software product" and it was designed very carefully by that projects architect to deal with those kind of hassles. Bill Nando wrote: > And in fact, the problem isn't at all limited to shared hosting. I wouldn't > frame it that way particularly. It's exactly the same if you're got your own > box and you need to host multiple instances of the same application. They > need to be isolated from each other because each can possibly have small > variations, if not when they are installed, perhaps down the line when the > customer asks for a small modification. > > In the end, it makes it more difficult to bring a mid or low priced product > to market, because you know in the back of your mind that multiple instances > of that product don't scale easily when it comes time to install them on a > server. I know that we could get a dedicated server and create multiple > instance of ColdFusion, one for each site, but then we'd have the added > responsibility and hassle of maintaining a webserver. I could also search > and replace all 2000+ instances of the references to the mapping in the app > every time we create a new instance of the application, but that makes it > more difficult to maintain the codebase and easily can introduce errors. But > either of these solutions aren't appropriate with a mid to low priced app. > We need to be able to install the app with a minimum of fuss and expense. > > I've been back and forth with CrystalTech on the mappings issue, and in the > end, understandably they just don't have a solution for us. If i run into a > mapping collision on their servers, and i do now more and more often - we > have about 40 sites with them, i can wait until they sell enough sites to > open up a new server, or spread things out even more with another provider. > Either way, it's a bit of a glass ceiling on the growth of our business > unless i rebuild the app to be non-dependent on mappings. > > Anyone considering building an app with CFCs that would be sold as a product > should consider this carefully before they use a mapping. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Roland Collins > Sent: Tuesday, April 12, 2005 6:08 PM > To: [email protected] > Subject: RE: [CFCDev] Problem Extending Root Application.cfc > > > We _really_ need to lobby for per-application mappings in the next go > 'round. System-wide mappings aren't always possible, especially in shared > environments. > > Roland > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Ben Forta > Sent: Tuesday, April 12, 2005 11:30 AM > To: [email protected] > Subject: RE: [CFCDev] Problem Extending Root Application.cfc > > Actually, you can, see http://www.macromedia.com/go/9ce734f4 > > Dan, if you create a CF mapping called root, will root.Application work? > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Steven Brownlee > Sent: Tuesday, April 12, 2005 11:14 AM > To: [email protected] > Subject: RE: [CFCDev] Problem Extending Root Application.cfc > > I was under the impression that you can't extend Application.cfc. Could be > wrong though. I'm sure someone more knowledgeable will chime in. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Daniel Short > Sent: Tuesday, April 12, 2005 10:51 AM > To: [email protected] > Subject: [CFCDev] Problem Extending Root Application.cfc > > Hi everyone, > > I'm having a terrible time trying to figure out how to extend the root > Application.cfc file in my site. I have an Application.cfc file in a > subfolder, and I've tried all of the following combinations without any > success. They all say that the sub/Application.cfc cannot extend itself: > > <cfcomponent displayname="Subfolder Application.cfc" extends="Application"> > <cfcomponent displayname="Subfolder Application.cfc" extends=".Application"> > <cfcomponent displayname="Subfolder Application.cfc" extends="/Application"> > <cfcomponent displayname="Subfolder Application.cfc" extends="\Application"> > <cfcomponent displayname="Subfolder Application.cfc" > extends=".\Application"> > <cfcomponent displayname="Subfolder Application.cfc" > extends="./Application"> > > > Anyone know how to make this happen? > > Thanks, > > Dan > > > > ---------------------------------------------------------- > 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] > > > > > > > > ---------------------------------------------------------- > 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] > > > ---------------------------------------------------------- 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]
