CFMAPPING: defining per-Application mappings
There's been an interesting discussion recently on the CFCDev mailing list regarding the ability to configure per-Application mappings, and a more general discussion of per-Application configuration settings on Ben Forta's blog. Based on these discussions and a specific request from a BlueDragon customer, we've decided to introduce the CFMAPPING tag in the upcoming BlueDragon 6.2.1 updater.
The CFMAPPING tag will have two required attributes--LOGICALPATH and DIRECTORYPATH--that correspond to the settings in the admin console:
<cfmapping logicalpath="/mypath" directorypath="C:\mymappedpath">
The LOGICALPATH and DIRECTORYPATH attributes will both accept variable expressions as well as string constants.
The DIRECTORYPATH attribute must specify a full physical path. When the CFMAPPPING tag is rendered BlueDragon will verify that the specified DIRECTORYPATH actually exists, is a directory (and not a file), and that BlueDragon can read from that directory; if any of these checks fail, a CFML runtime exception will be thrown.
Mappings specified by CFMAPPING will exist for the duration of the request and survive across CFINCLUDEs, custom tag calls, CFC method calls, etc. You can put a CFMAPPING tag where ever you want in your code, but the most logical place is probably within Application.cfm right after the CFAPPLICATION tag.
The CFMAPPING tag will override mappings configured via the admin console.
That's about it. If you have any feedback on this implementation there's still time--but not much--to adjust things before the BlueDragon 6.2.1 release, so let me know what you think.
P.S. I really like the idea of specifying per-Application configuration settings within Application.cfc instead of defining new tags as we've done here for CFMAPPING. But, BlueDragon doesn't support Application.cfc yet and we have a customer who has an urgent need for this feature, so creating a new tag seemed like the least disruptive way to satisfy his requirement. Also, even after we add support for Application.cfc, there are surely people who will stick with using Application.cfm, especially in legacy applications. When we do add Application.cfc support in the next major release of BlueDragon, we'll likely add the ability to specify a broader range of Application-specific configuration setting (including mappings) at that time.
I would like to be able to do the following as well, so that I can have possibly different directory structures on different environments that support the same mapping scheme:
<cfmapping logicalpath="/com" relativepath="../com" />
Of course, there could be a serious flaw with this that hasn't crossed my mind.
-Joe
And I like your reasoning Vince. The more i think about why a "local" mapping should necessarily be married to the application scope, the less i see why. True, it's today's need to have it more flexible so it can be set on a per application basis. But a mapping is simply a pointer to a location on the hard disk. The other features of CF that are related to the hard disk like cffile or cfdirectory or getdirectoryfrompath() are not application scoped. We would never think of them that way.