We actually host numerous instances of our own application, but the same
principles apply. We use a combination of a single server-level CF mapping
and application level variables to path our CFCs. So we _do_ still have to
create a mapping, but it is only _one_ for all of our instances. Our
directory structure looks something like the following:
\\InetPub\approot1
\\InetPub\approot1\cfc
\\InetPub\approot2
\\InetPub\approot2\cfc
\\InetPub\approot3
\\InetPub\approot3\cfc
So we add a CF mapping that points to \\InetPub. Then we have an
application variable named "CFCPath" that contains the approot and the cfc
subdirectory. So in this case, the CFCpath variable could contain
"approot1.cfc" or "approot2.cfc". Then, in our application, we refer to our
components like so:
<cfset myObject = CreateObject("component",
"#application.CFCPath#.MyComponent")>
This has been an _extremely_ effective way of maintaining application
isolation for us. Granted, it is still a bit of a work-around, but quite
frankly, unless you're running the Enterprise edition of CF (and who really
can afford that when you run multi-server clusters), it's one of the easiest
ways to achieve the necessary isolation.
As to inheritance - we don't really use it for the simple fact that it
basically limits you to a flat directory structure, an inverted directory
structure (in regards to the inheritance chain), or requires CF mappings.
I'd love to use it, but it is simply not practical given the current
limitations of CF. One day, I hope to be able to configure app-specific CF
mappings (and I've requested this as an enhancement for several version of
CF now). That would solve all of our issues.
Hope that helps!
Roland
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Nando
Sent: Friday, April 29, 2005 10:39 PM
To: [email protected]
Subject: RE: [CFCDev] Basic component inheritance path question
Dave,
If you're building an app that will be distributed widely, be a little
careful. We've got an app that we're selling to smaller clients, and
sometimes we run into trouble with the mapping for the app. At this point, i
see it as a restriction on our business - i can't market the thing too
widely because we'd run into trouble hosting the sites at the price point
that makes sense for this app. Either i'd need to provide hosting among a
lot of different web host providers, to spread the instances out 1 app per
server, which would be a real hassle for us to keep track of. And i'm not
too keen on experimenting with lots of webhosts. Or we'd need to set up
dedicated servers for our app and partition them into different instances of
CF. Whoops.
>From your post, it sounds like that's what you want to avoid. There are
moments when i wish i had seen ahead clearly enough to do the same, but from
a programming perspective, using mappings seemed to make so much sense. It
does!
Roland Collins works for a company that sells a widely distributed app, as i
understand it, and also from what i understand - so that he can avoid using
mappings - he avoids inheritance. He's also pushing for a way to create
application specific mappings with the next release of CF so he doesn't have
to hamstring the way he uses CFC's in his apps.
If he could post a summary of points how they structure their application to
avoid the use of mappings or custom tag paths, so it's just plug and play, i
think that would be pretty keen. From what i've seen, he's thought this thru
carefully. I'm wondering about rebuilding our app in such a way myself.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Dave Merrill
Sent: Friday, April 29, 2005 9:05 PM
To: [email protected]
Subject: [CFCDev] Basic component inheritance path question
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]
