> I have followed this thread not too closely, and maybe this seems like a > dumb question, but.... what is the big advantage of per application > mappings?
The big advantage comes down to "scope" i suppose. As it stands, mappings are set, if you will excuse any technical inaccuracy in my statement, in "server scope". Practically, that's how it works. The problem arises if you want to use the same mapping twice on the same server. I'll get to why you'd want to do that in moment. Let's say you only had server scope available to code with and every time you used a cfset tag it would affect the whole server. Realizing that this would cause utter havoc, cfset was made available only in the cf administrator to make sure variables were only set in one place, to enforce integrity. That would make things kinda difficult, wouldn't it? People would be trying to set variables in Java. (Which is how this thread got started). And that's more or less how mappings are handled today. That may seem like an extreme analogy, but as we use CFC's more and more, mappings become a critical center point around which applications revolve. A mapping, just like any other variable, might be "dereferenced" many times during a single request. It can be very helpful to have the mapping variable "application scoped" instead of "server scoped". And if you think about it a moment, it makes complete sense, because 98% of the time, a mapping is relevant to an application only and not to the whole server. That's a guesstiimate, but i think it's often the case. CFC's become more difficult to use without mappings as the number of CFC's increase in your codebase. At present, one of the "best" workarounds to avoid using a "server scoped" mapping - for the purpose of code portability - seems to be to put all of your CFC's and any code that calls them in the root directory of your application, which is a horrible workaround. It kind of implies that you should put all of your code in the root directory. Who knows when and where you'll need a CFC when you need to design to accomodate change? At least you can still put images in an /img directory! Of course, there are better ways to fudge this workaround, but i've seriously considered it. With a naming convention and underscores, i could simulate a directory structure and just put all my code in the root directory and not use mappings. Why would i do something so absurd and likely counterproductive? because ... for me, the really big advantage in the bigger picture is it would allow me to simply and easily package a product that is meant for distribution and deploy / host many instances of that app on a webserver, without needing to change the codebase each time and test each of them to make sure i haven't introduced any bugs. I can do that for 20 or 30 or 40 installations, but a business model that requires 100's or 1000's of instances of the app is going to be increasingly difficult to support. because ... for each of those 100's or 1000's of versions, you'll have essentially the same application but a different codebase. with CFMX7, you might have a different *compiled* codebase. and any maintenance or bug fixes are going to be simply painful. if you manage to get through the deployment OK - at a profit, the maintenence / bug fix might still sink you. whenever you look at a business model of 1000's of instances of an app, your profit margin per instance is of course much smaller. so you need to do everything you can to save effort and potential effort on each deployment. because ... i could work on different variations of the same codebase on my dev machine without needing to change the mapping in over 1800 places in my codebase. I can't believe there are that many references to the main mapping i'm using in there, but there are! and i need to sometimes quickly work up variations and try different branches out. my best workaround right now is to set up multiple dev environments so that my branches aren't filled with different-yet-same code, but that takes time. Yes, workarounds exist and are useful. But when i add it all up, the lack of application specific mappings seems to be fairly costly in certain circumstances. Of course, if i were working in a one app per server corporate environment, server scoped mappings would likely be perfectly sufficient. But in smaller shops developing apps to deploy multiple times, it seems many of us are running into a rather urgent need for application scoped mappings (or to drop the use of mappings entirely, and make whatever sacrifices are necessary). Nando > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Chris > Sent: Sunday, October 02, 2005 9:29 AM > To: [email protected] > Subject: Re: [CFCDev] Per Application mappings WAS: Java CFCProxy info? > > > Hi guys, > > > I agree. CFMAPPING would be more-flexible than another attribute in > > CFAPPLICATION. If this is finally implemented in CF, I certainly hope > > the values allow for dynamic variables and not just hard-coded values. > > I have followed this thread not too closely, and maybe this seems like a > dumb question, but.... what is the big advantage of per application > mappings? > > If you only want to access resources within the web root, you could > simply use variables that contain paths (which you all do in one way or > other, I feel sure). > > But, if you want to access resources outside the web root, wouldn't that > be a security risk? Imagine a hoster with x clients, where each client > could define mappings and data sources and thus could access other > clients' data sources or maybe even system paths? > > I think that if you offer such a feature, there also must be the > possibility to disable it in the admin interface. > > Best, > > Chris ---------------------------------------------------------- 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]
