I like the java standard notation of reversed domain name, but it doesn't
work in a shared environment. Swapping the first period for an underscore
gives you the same benefits, without the collisions, though.
So rather than organizing like this:
Com/
mydomain/
myapp/
cfc1
cfc2
Do it this way:
Com_mydomain/
myapp/
cfc1
cfc2
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Nando
> Sent: Wednesday, November 19, 2003 1:52 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] cfc paths
>
> Nathan,
>
> <snip>
> Other than the issue of name collisions on multi-home
> machines, what else
> are you looking for clarification on?
> </snip>
>
> I'm trying to understand if name collisions are really an
> issue on a shared
> hosting environment, and if so, figure out a naming strategy
> that would
> pretty much ensure uniqueness, which is not too difficult to
> do, but as i
> think someone else pointed out, it's a pain in the ass to go
> through your
> whole application and rename all the references to all your
> components for
> every new application you reuse them in. So before i set
> myself up for that,
> i want to make sure that this is really an issue, and
> understand what the
> issue really is.
>
>
>
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Behalf Of Nando
> > > Sent: Wednesday, November 19, 2003 10:42 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [CFCDev] cfc paths
> > >
> > >
> > > Hi all,
> > >
> > > <snip author="Massimo">
> > > The issues raised by Jim are important, but they scare me much
> > > less than the
> > > risk for name clashing... I don't pretend to say relative
> paths are the
> > > ultimate solution, but we have a problem, a pretty serious one,
> > > and we need
> > > a solution.
> > > </snip>
> > >
> > > I've been following this thread, and i'm wondering if this is a
> > > "confirmed"
> > > problem, especially as Ben Curtis couldn't replicate it. Right
> > now, i have
> > > all my components under a "com" subdirectory and the site will be
> > > hosted on
> > > CrystalTech. And they all have pretty ordinary names,
> like Person, Text,
> > > etc. So the potential for a clash, if this can actually
> occur, is pretty
> > > high with my naming scheme so far.
> > >
> > > <snip author="Robby">
> > > I'm on Crystal Tech as well Jim ... I noticed when they brought
> > > in the 'add
> > > your own mappings' that they have reserved the com
> mapping. I love the
> > > convention, but I could see why the death of it's use on their
> > part. Heh,
> > > try being a mach-ii developer to boot. From what I gathered in a
> > > light email
> > > conversation with a CT tech on the issue it's been going off
> > the hotplate
> > > faster than domain names on ebay in the 90s. All in all
> when it comes to
> > > conventions such as package naming, ColdFusion and sharedhosting
> > > isn't going
> > > to play nice. period.
> > > </snip>
> > >
> > > Ummm, that's a little confusing ... so I thought I'd write
> > CrystalTech and
> > > ask them directly why that mapping was reserved on their system
> > ... here's
> > > the answer i got back:
> > >
> > > <snip author="CrystalTech Support">
> > > It is reserved by MX6.1, not our system. Therefore,
> there should be
> > > more information about that on their website www.macromedia.com .
> > > </snip>
> > >
> > > ??? - Well, that didn't help. I can map to a subdirectory named
> > > "com" on my
> > > dev installation without any problem.
> > >
> > > <snip author="Macromedia LiveDocs">
> > > http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_
> > MX_Applica
> > tions_with_CFML/buildingComponents5.htm
> >
> > When you refer to a component using the fully qualified
> name, ColdFusion
> > looks for the component in the following order:
> >
> > * ColdFusion attempts to resolve the physical path from
> the request,
> > such as /com/mycompany/catalog/product/saw.cfc, to a component
> > file located
> > in directories under the web root or directories under ColdFusion
> > mappings.
> > * Otherwise, ColdFusion attempts to resolve the
> physical path in the
> > custom tag root, such as
> > {customTagRoot}/com/mycompany/catalog/product/saw.cfc,.
> >
> > When a component is invoked using any of the interfaces mentioned
> > previously, ColdFusion generates the key name in the
> component metadata
> > structure in the following order:
> >
> > * If a component file exists in a directory accessible
> by ColdFusion
> > mappings, use GetRealPath function to evaluate the component
> > physical path.
> > The URI path string after .cfc and the leading slash is
> removed, and all
> > slashes are replaced with dots.
> > * Otherwise, ColdFusion loops over the custom tag roots
> > looking for the
> > ancestor directory of the component. The physical path string
> > after the root
> > path and file extension are removed, and all slashes are replaced
> > with dots
> > * Otherwise, ColdFusion uses the file name without the
> > extension as the
> > component name.
> >
> > </snip>
> >
> > Ok, now i'm totally lost. If anyone can clear something up here, i'd
> > appreciate it -
> >
> > Thanks!
> >
> >
> > ----------------------------------------------------------
> > You are subscribed to cfcdev. To unsubscribe, send an email
> > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> > in the message of the email.
> >
> > CFCDev is run by CFCZone (www.cfczone.org) and supported
> > by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
