I haven't lived in America for 25 years, so i'm probably not up on the use of the word "evil" in everyday speech. But in my very direct experience, for those of us that are creating applications to be distributed on anything "less" than a dedicated server, server-wide mappings tend to create bigger problems than the ones they attempt to solve, and it's very possible you might not see it coming.
On a larger scale, for all the reasons Roland lists, they limit your ability to create a viable business with what needs to be a plug and play application. I've got nearly 2000 instances of a mapping in our code base. And the app isn't THAT big. Once you start relying on CFC's, mappings, if you use them, are all over the place. I would add to his list that whenever you are forced to search and replace the mapping so you can install a separate instance on a server ... you make it "twice" as difficult to maintain your codebase across installations with bug fixes and improvements. That can get out of hand exponentially! To expand our business, either we're going to have to modify our codebase and move toward what Roland is doing, perhaps using a single directory for all CFC's so i can use inheritance. Or wait until CFMX has application specific mappings. We had a provisional offer to include our app within another much larger online service. They wanted it now. I backpedaled largely because of the mapping issue, and the deal fizzled. It might have fizzled anyway if i had gone for it, but i couldn't really take the first step forward. Is that evil? Well, let's just say it was a little unfortunate. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Collins Sent: Tuesday, May 03, 2005 8:11 PM To: [email protected] Subject: RE: [CFCDev] Basic component inheritance path question Mappings are evil! For one, you don't always have access to the admin or admin api to add said mappings. Secondly, using mappings prevents you from using "copy and deploy" style methodologies. Finally, mappings allow all other applications within the same instance direct access to call your code! Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrocknaphobia Sent: Tuesday, May 03, 2005 12:47 PM To: [email protected] Subject: Re: [CFCDev] Basic component inheritance path question What do you see as detrimental in specifying a mapping via the CFAdmin? -Adam On 4/29/05, Dave Merrill <[EMAIL PROTECTED]> wrote: > If you want components in various physical locations to inherit from some > app-specific classes, where would you put those ancestor classes physically? > > The 'extends' property of a component wants a static string, not a variable. > So, the paths it sees have to either be in the same directory as the > descendant component (not practical for common ancestors to components in > many locations), or they have to be full paths. For a full path, if it's > from the web root, it breaks if you move the app or deploy somewhere with a > different directory structure. If that happens, or you want to guard against > the possibility, you could create a mapping whose logical path is the same > as the canonical app root you used in your 'extends' properties, pointing to > the actual app root. Right? > > So either your app has to be installed in a specific location relative to > the web root, or a specific mapping to where the app actually is has to be > created on any server you deploy to. > > Is this the state of the art, or am I missing something obvious here? > > Thanks, > > Dave Merrill > > ---------------------------------------------------------- > 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]
