Copy link to clipboard
Copied
Pretty straight forward here, I have defined this.customTagPaths to include two directories. Within both of those directories I have a script, lets say test.cfm, with different contents. For discussion lets say one writes out "You found tag 1", the other writes "You found tag 2".
I then call <cf_test>, and the result is the same no matter what I do to the order of directories listed in this.customTagPaths. My application has a this.name, and I've tried changing it at the same time I change this.customTagPaths. I've tried renaming the tag directories to see if possibly it was sorted by name. I cannot find a reliable way to predict which tag will execute.
Using <cfmodule> is not an option at this point.
Currently testing in Windows, CF11.
Copy link to clipboard
Copied
I hate to sound trite, but having the same name for different scripts, even in different CustomTag directories, and trying to jumble it all up and see if there is a rhyme or reason to how it's "sorted" is just plain bad coding. Period.
I'm not trying to be insulting. I'm calling it as I see it. This does not make sense. Are you doing this just to see what will happen? I sincerely hope you are not planning on making this into a production application.
V/r,
^_^
Copy link to clipboard
Copied
Call it however you want. This doesn't help me.
But since you threw in a dead end to my question, I'll explain. I have a tag library that is used by several dozen installs of a single application. One of those installs has to do something just slightly different than all of the others. I want to override one tag by adding a second customTagPath to the Application.cfc and then placing that modified tag in the directory. I don't want to modify all of the other scripts that call that tag. I don't want to modify all of the other installs. I don't want to copy the entire tag library to change one tag. I simply want to understand which is chosen and why.
Per the CF9 docs:
Custom Tags in per-application settings override those defined in the ColdFusion Administrator. For example, if you have two custom tags of the same name and they are in different locations in the Administrator and per-application settings, the one in the per-application settings is taken first.
Adobe ColdFusion 9 * Elements of a ColdFusion application
If Cf has a logical preference for per-app tag paths over server-wide tag paths, why doesn't it within multiple per-app tag paths?
Copy link to clipboard
Copied
@WolfShade has a point. But so do you, @Mvierow .
No two tags in ColdFusion share the same name. It would therefore be confusing to have custom tags, which simulate ColdFusion tags, to share the same name.
Nevertheless, two custom tags of the same name, located in two different directories, may encourage polymorphism. This is a good thing. In fact it is one of the cornerstones of object-oriented programming. It all depends on how you implement the custom tags.
mvierow wrote:
If Cf has a logical preference for per-app tag paths over server-wide tag paths, why doesn't it within multiple per-app tag paths?
The answer to your question is: because ColdFusion lists are unordered. This.customTagPaths is just a comma-delimited list, and there is no concept of who comes in the list.
There is another fact that may complicate your design: caching. Suppose that, on the first run, ColdFusion picked the custom tag named test.cfm from the directory X. (By our assumption, X is just one among many directories in this.customTagPaths containing the file test.cfm). For efficiency, ColdFusion would have cached the class file of that CFM page after compilation. I would imagine that, when subsequent calls are made to the custom tag page, ColdFusion first checks to see if there is a compiled copy of the page from any of the custom tag directories. And - presto - that is probably what you have been observing.
ColdFusion first looks for a custom tag file in the current directory. That is, in the directory where the call <cf_test> is made. So, there are at least two sure ways to solve the problem.
One way is to drop a copy of test.cfm in the current directory. But this is shoddy design, as it mixes ordinary pages with custom tag pages.
A second, better, way is to use cfimport. You would then have to copy test.cfm to the appropriate custom tag directory. This can be anywhere under the root. Example usage (here customtags is a subdirectory of the current directory):
<cfimport prefix="xyz" taglib="customtags">
<xyz:test>
Copy link to clipboard
Copied
Thanks for the thoughts and efforts to share them BKBK
No two tags in ColdFusion share the same name. It would therefore be confusing to have custom tags, which simulate ColdFusion tags, to share the same name.
...
The answer to your question is: because ColdFusion lists are unordered. This.customTagPaths is just a comma-delimited list, and there is no concept of who comes in the list.
ColdFusion hotfixes and the Java Classpath are some possible challenges to these statements. Debating not really worth either of our energy I imagine.
Re: caching, seems very plausible. It could be that the absolute path to the tag via customTagPaths is checked, in logical order, for a compiled/cached version first and only if a cached tag is not found will it go through customTagPaths looking for non-cached tags. There'd never be a reliable chance for this one-off application to find anything but the common tag with so many copies of the application running unless I could isolate the one-off application from all of the others. That's something I haven't tried yet.
I agree on the shoddiness of same directory custom tags. Being able to disable this via Application.cfc sure would be nice.
I didn't dive too deep into cfimport, but perhaps there'd be a way to use it by calling it several times with the same prefix. Of course that would require rewriting all of my custom tag references. If I decide to go that far, another method would be to use cfmodule and use my own routines for defining which tag is called. So there's definitely a solution here.
Thanks for helping me bring these other options into focus.