the most flexible solution to the whole problem. Right now, the resolution
of CFC names is:
1. Current Directory
2. CF Mappings
3. Custom Tags
If the application specific "CFCPATH" attribute was added to the
<cfapplication> tag, then the paths in that attribute could be searched
first. If not found, then CF could search just like it currently does.
Also, <cfapplication> might not be the best place to put this. How about
the <cfsetting> tag?
<cfsetting cfcpath="C:\WebSites\site\cfc;C:\WebSites\lib"/>
While I'm at it, how about defining CF mappings for an application:
<cfsetting
mappings="com.domain=C:\WebSites\site\cfc;com.domain.cfc=C:\WebSites\lib"/>
The reason I say this is that if you put this in the cfapplication tag, you
cannot access the "application" or "session" scopes to obtain any dynamic
values to use in the setting value. What if you had a variable that
contained to name of the root directory for your cfcs? I'm not saying I
would do that--I would problably use the request scope, but the point is
that you might want to have access to those scopes before defining the
cfcpath attribute.
<cfsetting cfcpath="#session.workspaceName#\site\cfc;C:\WebSites\lib"/>
What I just did was define a cfc root for the current developer's workspace
directory. This would allow for concurrent development on the same sets of
components in different locations on the same server--and the full names
wouldn't have to be changed for each workspace.
Anyhow, thanks for bringing this up. I wonder if they would do this for us.
Paul Kenney
WebMaster, CorporateWarriors.com
916-663-1963
-----Original Message-----
From: Barney Boisvert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 9:15 AM
To: CF-Talk
Subject: CFC location issues
Excuse the long email, but I think I've found a potential solution to a
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]
