problem that has plagued myself and others.
There seems to be two main routes to handle placing and referencing CFCs
(I'd love to hear of others):
1) Put the CFCs in a "proper" place, such as the web root, or a mapping with
the "/com" path, and use their full paths throughout your CFCs to type
arguments and return values. This is ideal, though it limits you to a
single app per CF instance.
2) Put the CFCs in a app-specific place (within your app root), and use a
application variable to store a the "stuff" that goes before the "com." in
your package name. You name CFCs using that application variable
("#application.cfcroot#com.mydomain.myapp.mycfc"), and leave your CFC
arguments and return values untyped (because they can't use dynamic names).
Option 1 is perfect for dedicated servers (or CFMX instances) with a single
application running on them. Option 2 is usually what people resort to in
shared environments, and also the best I've come up with for dev servers,
where you necessarily have multiple versions of the same application running
(such as a development CVS working dir, and then need to check out the live
one for a quick fix).
As I was driving in to work today, I thought to myself, "Gee Barney, Java
has the perfect solution to this, the CLASSPATH, why doesn't CF have one of
those?" So I thought I'd pass the idea around, and see what people thought
before I go running to Macromedia. I'm not sure the best way to implement
it, but the CFAPPLICATION tag seems like a prime candidate:
<cfapplication
cfcpath="/path/to/dir,/other/dir" />
Then you could define the search path for CFCs at the application level
(where it really ought to be, IMHO), rather than at the server instance
level (which only works for dedicated instances, where server and app are
the same level). That would also let you define the search path with your
application config, rather than the server config, which has benefits, at
least to me.
Still have to have the server-level mappings and whatever else, but this
would put control of CFCs back in the developer's hands, not in the server
admins.
What do people think about that kind of solution? I think it's a good one,
but then I thought of it.
Cheers,
barneyb
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
[EMAIL PROTECTED]
voice : 360.756.8080 x32
fax : 360.647.5351
www.audiencecentral.com
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
