> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Chris
> Sent: Sunday, October 02, 2005 3: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).

The entire issue revolves around CFC mappings.

Currently without a mapping you can't use many CFC features, especially when
you you'd like to package your CFCs.  Extending a CFC with a CFC in another
folder, type validation of CFCs, invocation, etc all essentially require
mappings.

Application-specific mappings would let you set such things at the
application-level.  Thus two applications could have the same mapping name
(allowing, for example, two people on a shared server to use the same
pre-packaged application but not share code).

They would let you construct and implement mappings at run time allowing you
to construct intelligent application installers and such.

A more general "<cfmapping>" tag (not application-specific) would solve many
of the problems as well but still would (I think) force the mappings
generated to be unique across the server.

This is a problem we know how to deal with however (needing to deal with it
for DSN and Verity names as well) so it's not that big a deal.  (Although
application-level DSNs and Verity names would be nice as well.)

Jim Davis




----------------------------------------------------------
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]


Reply via email to