Debate: The Best Way to Invoke Custom Tags

How do you invoke custom tags? Do you use the CF_MYTAG approach, or do you use CFIMPORT? I started out using the CF_ technique, but now I find I prefer to use CFIMPORT for the following reasons:

  1. I like the flexibility it gives me in terms of where I can put my custom tags (without having to create mappings).
  2. I like the ability to create “packages” or groups of related tags, which allows me to reuse tag names.

The Jimg project from DRK 4 comes with a set of custom tags for image manipulation: border, crop, draw, fill, height, load, pattern, rotate, save, scale, scaleToAtLeast, sequence, size, text, tint and width. I certainly wouldn’t want to copy all those tags in my CustomTag directory and take the chance of overwriting existing custom tags. Rather, I copy create a directory called “jimg” in my /cf_tags directory, and import them like this:

<cfimport taglib="/cf_tags/jimg" prefix="img"/>

Then, I can use the tags like this:

<img:sequence>
<img:load .../>
<img:scale .../>
<img:save .../>
</img:sequence>

What’s your preference, and why?

17 Responses to Debate: The Best Way to Invoke Custom Tags

  1. tc says:

    I prefer the import method also. I also appreciate the fact that in the 6.1 documentation, they have updated the cfimport tag’s documentation to state that it can be used this way. The way I found how to use it in 6.0 was through the Petmarket HTML version example app. It wasn’t documented.

  2. Ben Forta says:

    Don’t forget <CFMODULE>, that’s your third option.

  3. tjarko says:

    Can you scope the CFIMPORT?? the thing that’s holding me back is the fact that with every page request I have to “collect” all the tags and I regain that’s a performance issue??? Now if you good scope it.. like session.img then you only have to “collect” the tags once… i’m not sure if that is possible?? anyone?

  4. I’d like to ditto Ben. CFMODULE is probably the _best_ way to call custom tags, especially if you plan on deploying to a server w/ many other apps. It let’s you explicitely state which path CF should use to find your tag, so you don’t have to worry about occlusions.

  5. ... says:

    Ben, Ray, do you use <CFMODULE TEMPLATE=”normal/path/to/tag.cfm”> or <CFMODULE NAME=”dotted.path.to.tag”> ?

  6. Dennis Spaag says:

    Ray, why would CFMODULE be better? Looks like CFIMPORT allows them to be placed whereever desired – without needing to be mapped. Is that not correct? Is CFMODULE faster? More stable? Thank you.

  7. In reply to …I use foo.goo.zoo where foo is a mapping.In reply to Dennis:CFIMPORT is fine, but you have to reimport on each page. This is not _bad_ per se, just a bit of a pain at times. I can run CFMODULE FOO w/o having to import the files first.Again, I am NOT knocking CFIMPORT at all. Actually, I’d say they are equal and it’s just a a metter of syntax.That being said, CFIMPORT lets you do some ver nice things like, import JSP taglibs – import and map to * where EVERY tag can be parsed (this means you could rewrite the body tag if you wanted).

  8. I’ve become a big fan of CFIMPORT. I always felt that CFMODULE was clumsy syntax, and I wished and prayed for a way to set a custom tag path in my Application.cfm somehow. CFIMPORT achieves almost all of what that would have provided.It would be fantastic, though, if there were a way to CFIMPORT in some global fashion. Perhaps an attribute of CFIMPORT like propogate=true, so you could have CFIMPORT statements in Application.cfm and have them honored on all subsequent pages. Based on the way the pages get compiled that’s probably not possible, but it would make code maintenance much easier.

  9. Robby says:

    Just to say I second nathan, an application based call would be nice, if not dynamic paths would be a godsend.I asked on the cfcdev mailing list a couple weeks ago whether anyone seen any overhead with using cfimport (I use it on all ui, form, security controls) The general concensus said no on the overhead, . but whats been said above was echo’d all throughout the responses.Cheers

  10. John Farrar says:

    CFImport defies dynamic usage while trying to create dynamic usage. You can not pass a “variable” to tell the page where the tag directory is. This is sad, it would be everything people are saying here… and more if that one issue could be corrected. (Also… site wide would reign over page by page.) For that reason, we are still using CFModule… the dynamic nature seems to be more important to us than the saved typing.

  11. Marc Wallace says:

    My problem with CFMODULE is that it doesn’t give you attribute validation.With CF_MYTAG you can modify the validator so it knows what attributes a commonly used tag uses. This is especially useful in large intranet app projects.Certainly you can (and should) still CFPARAM them in the custom tag… but the validation is a nice step. Helps keep you from mistyping that optional parameter, then wondering where the value went…

  12. Florida says:

    I prefer the import method also.

  13. I think the CFMODULE would be better. Looks like CFIMPORT allows placement whereever desired – without being mapped.

  14. Tariq Ahmed says:

    I just started experiment with the cfimport… I got a big beef with not being able to put in a variable in the taglib parameter. I don’t want to assume that something is always off the root, and if you change around the directory structure you gotta do a mega search and replace. With CFMODULE we have an Application var that tells the app what the root level is, similar to a context root. You should be allowed to

  15. michael muller says:

    The best option for me would be the allowance of paths in the method. I have templates which are authored by designers and it’s all I can do to get them to work with the tags as I write them (trying to keep some of the attributes standardized between tags). There’s no way I’ll be able to get them to start using cfmodule or the syntax provided by the cfimport tag.Maybe something like this could be used to temporarily set the first custom tag path for the life of the page?

  16. michael muller says:

    Woops… let’s try that again.The best option for me would be the allowance of paths in the <cf_myTag> method. I have templates which are authored by designers and it’s all I can do to get them to work with the tags as I write them (trying to keep some of the attributes standardized between tags). There’s no way I’ll be able to get them to start using cfmodule or the syntax provided by the cfimport tag.Maybe something like this could be used to temporarily set the first custom tag path for the life of the page?<cfsetting customTagPath=”tempPath”>