Or perhaps a new CFMAPPING tag that sets a dynamic mapping that's specific
to the current request. Not sure how that would play with CFIMPORT (as it
can now use mappings, but only at compile time), but I could see it
potentially helping on that front.
Cheers,
barneyb
> -----Original Message-----
> From: Paul Kenney [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 02, 2004 10:05 AM
> To: CF-Talk
> Subject: RE: CFC location issues
>
> This solution occurred to me too a while back, and I think it
> is probably
> 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:\We
> bSites\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]
