I can only agree whole heartedly with this add a few things:
I'm also on CrystalTech and released a CFC-heavy application recently.
Worked a treat. I stored my (many) CFCs in the folder
"com.depressedpress.CFCs" - obviously at this point it was searching
from the web root and finding everything well.
At some point somebody created (CrystalTech allows you request mappings)
a "com" mapping on the same server - now everything broke, nothing
found. I changed my folder to "cfc_ComDepressedPress", created my own
mapping and everything worked.
However I also had to change all of my internal CFC references (there
are several cooperating packages). This also means that I can't easily
distribute by packages as somebody else must set this mapping - and it
may be (as it was for Massimo) that two virtual servers on the same
machine may want to use the same packages but different revisions.
Since the mappings are searched before the web root (which makes sense
for dedicated servers, but not for shared hosts) this AND since we can't
dynamically set the path to CFCs this is effectively impossible to do.
I know you can "sort of" get around this by not specifying any path for
the CFC (in which case CF won't use the mappings) but that leaves a lot
of ambiguity if you may have like named CFCs (for example two companies
may easily distribute different CFCs called "user" or "customer" - and
would want to distinguish their own via a fully-qualified name).
As a suggestion I've always thought that a possible solution would be to
allow setting this kind of information at the application level, perhaps
with an "CFApplicationParam" tag. You might then do this:
<cfapplication name="myApp" sessionmanagement="No"
clientmanagement="No">
<cfapplicationparam type="CFCPath" name="com"
path="e:/mysite/com">
<cfapplicationparam type="CustomTagPath" name="CustomTags"
path="e:/mysite/Assets/CustomTags">
</cfapplication>
In this case the two mappings specified would be searched BEFORE the
server mappings for any request that's part of the application. Many
other settings could also be made like this to override or augment admin
settings for specific applications (it would be nice, for example, to be
able to turn on the debug service for specific application but not all).
Yes, this does depend on people using the application framework, but
that's a small price to pay, I think. The same thing could be done with
<CFSetting>, <cfprocessingdirective> (or something like them) at the
request level, but I think maintaining it at the application level makes
more sense.
Of course a very nice solution would also be to allow truly dynamic CFC
names as in:
<cfcomponent extends="#MyCustomMapName#.DPRoot">
or
<cfargument name="Festival" type="#MyCustomMapName#.DPEvents.Festival">
or
CreateObject("Component", "#MyCustomMapName#.DPException")
However while this would be GREAT it's also obvious that it may mean
touching a lot of core code and could even impact performance. Using
the application configuration as I've suggested seems only to add a
small amount of storage management and modification of the CFC discovery
code.
What do you guys think?
Jim Davis
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Massimo, Tiziana e Federica
> Sent: Thursday, November 13, 2003 4:19 PM
> To: [EMAIL PROTECTED]
> Subject: [CFCDev] Why we need the ability to use a path to specify the
> location of a CFC we want to call (long)
>
> I keep asking this since long ago, many top developers may not see the
> need
> for it, because they mostly work on dedicated server. People that
tried to
> use CFCs on a shared box will see my point more easily (I work both on
> dedicated and shared boxes). This is a real horror story that will
prove
> why
> we need call a CFC using a relative path, just like <cfmodule> can do
with
> custom tags.
>
> Early this year I released to the public a CFC for basic image
> manipulation,
> a few hundreds people downloaded it (v 1.2). More recently, CF 6.1
with
> the
> included JRE 1.4 gave me the opportunity to update the CFC and add a
few
> additional functionalities.
>
> I refactored the CFC, keeping 100% backward compatibility to avoid
> breaking
> existing apps. I added a few methods/features and, since I was there,
I
> realized that providing a default value for the dimensions of the
> thumbnails
> it generates made a lot of sense (again, without affecting existing
apps),
> so I set it to 100px. The job went fine, so after a few iterations I
> released this one too (v 1.6 than 1.8). This time a few hundreds more
> people
> downloaded it (total should be around 800).
>
> Yesterday I started getting error notifications from an application
that
> was
> already running fine for a while. The error said the "thumbWidth"
> parameter
> was required. That's exactly the parameter that was required inside
> earlier
> versions of my CFC but not anymore! The version on my app folder was
the
> latest and greatest; I even upload it again but still no joy.
>
> Suddenly I realized what was happening, another application was
calling an
> older version of my CFC using the same dot notation I was using on
mine!
> The
> host is pretty popular among CF geeks (Crystaltech), my company
maintains
> two others apps on them, so I checked the other apps; they were using
the
> latest version too.
>
> Another user, I will never know his name, was using the older version
of
> the
> CFC on the same box, CF server caches the location of the CFCs (just
like
> it
> does with custom tags called with the <cf_mytag> syntax) and I had no
> control over it. Only solution was to move my CFC in a different
location
> and hope the resulting dot notation was unique. In the end, I fixed
the
> issue rather quickly, but I really got the urge to share the story.
>
>
>
> Years ago, the ability to use <cfmodule template="../myTag.cfm">
solved
> two
> problems regarding custom tags:
>
> 1) Avoid name clashing caused by CF Server caching the location of
> custom tags
>
> 2) Make it easier to deploy self contained CF apps
>
> History is repeating itself, we are facing the same issues with CFCs,
and
> we
> need something to the rescue.
>
> I have a few more CFCs that I plan to polish and release to the
public,
> with
> a few sample apps the use them. The apps will be self-contained, "plug
and
> play". But if people will use them out of the box on a shared server
they
> may face the same horror I reported above. I have to avoid
distributing my
> stuff or hope people will understand my instructions on how to make
the
> locations of the CFC (and the resulting dot notation) as unique as
> possible
> (and hope for the best too!).
>
> I feel the pain for people that distribute CFC based commercial
> applications, they have to choose between making the apps harder to
set up
> and running, and hoping two different users will never run
> different/modified versions of the CFCs out of the same box. That's
weird!
>
>
> Sorry for the long rant, but I think this is an important issue, I
already
> reported it to MM and I hope others will cast their vote too:
>
> http://www.macromedia.com/support/email/wishform/
>
> ----------------------------
> Massimo Foti
> Certified Dreamweaver MX Developer
> Certified Advanced ColdFusion MX Developer
> http://www.massimocorner.com/
> ----------------------------
>
>
>
>
>
>
> ----------------------------------------------------------
> 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]
