Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

Calling all custom tags

Calling all custom tags

You probably know about custom tags, but are you aware of all the possibilities for controlling who can access them and how?

Perhaps you knew that a custom tag could be placed in the cfusion\customtags directory of the CF server to provide shared access by all users on the server, and you may even know that a tag placed in the same directory as the calling template will be found first (we'll call this a "local" custom tag).

But what if you want to share a custom tag — not among everyone on the server, but among only a handful of applications not even in the same directory? How do you solve that problem? This is also a real problem on hosted servers, where perhaps you're specifically precluded from adding to the shared customtags directory. What if you want to share a custom tag among several of your applications? Do you believe you have to place a copy in every directory you have on that server? That would negate almost entirely the benefits of easily reused code!

And have you ever wondered if you could literally prevent someone from executing a custom tag? (Still another benefit important to those on shared servers.) Or did you know you could code your app such as to prevent someone from overriding a call to a shared custom tag with a local one? (Both these concerns would also be important in secured departmental or organizational environments.) Last, what if you wanted to call a custom tag whose name was in fact driven by a variable? All these things, and more, are possible.

There are at least six ways to control how and where a custom tag is called. In this month's Journeyman ColdFusion article, I'll expand upon these topics and discuss not only the language aspects of calling custom tags but also some advanced security aspects to control access to custom tags. We'll even throw in a couple of alternative ways of reusing code that are not quite custom tags but may be interesting to you.

For the Basics

In the February CFDJ (Vol. 2, issue 2), Ben Forta wrote a great article that included discussions of the basics of using and calling custom tags. He explained the important differences between using custom tags and CFINCLUDE and he alluded to a couple of advanced approaches to calling custom tags.

In case you're new to custom tags, let me simply restate that they're a great way to reuse code in ColdFusion applications. They're simply CFML files (C++ is supported as well) that perform some routine you may want to execute from within more than one template (.cfm file). The code in a custom tag is "called" using special CFML language syntax. I'll describe all those approaches as well as explain when and why you should use each approach. Location, Location, Location

Given that the key benefit of custom tags is reuse of code, a very important aspect of using them is paying attention to just where the custom tag is stored so it can be shared among multiple programs. Of course, like all CFML files, it's to be placed on the ColdFusion server. But beyond that, there are important considerations that affect the choice of location as well as the language syntax used to call them.

Some folks are under the mistaken presumption that there are only one or perhaps two places where they may be stored. In fact, you can place a custom tag anywhere on the ColdFusion server. This has tremendous and often untapped benefits for sharing a custom tag among everyone on the server, just those in a particular application directory or those within a logical group of applications. That last choice is the one that many may not know. Knock, Knock

The first matter to clarify concerns the many ways to call a custom tag. This is a quick reminder of the various approaches, with explanations of why you would use each approach. There are basically three approaches to calling them, with a couple of variations for spice.

CF_

Perhaps the most common approach that people will know is to refer to the custom tag by way of calling it with the "cf_" prefix. That is, if we had a custom tag called "format.cfm", we could call it via:

<cf_format>

Notice that the file name of the tag follows the "cf_", while the .cfm file extension is not used in the reference. When this code is encountered in a template, that first template is effectively placed on hold while the code in the custom tag is executed. The output of the custom tag, if any, is simply accumulated along with the output of the caller.

Again, just as a quick refresher, Figure 1 depicts a call to a very simple custom tag. What the custom tag does isn't really important (it simply causes text passed to it to be converted to uppercase and wrapped in HTML italics tags), but if you're new to using them, you can also see the means by which data can be passed to and used within a custom tag (providing parameter=value pairs after the call to the tag and use of the "attributes" prefix within the custom tag to refer to the passed parameters).

While this depicts the custom tag creating output that would simply be available as part of the output of the caller (when sent to the browser), it is possible — and sometimes highly desirable — to return data to the caller instead as a variable that can be processed entirely under the control of the caller. This involves using the "caller." prefix in the custom tag to create such a variable, which would be available in the calling template — a subject beyond the scope of this article, but hopefully this is enough to get you started if you're new to it.

So that's a quick reminder of how custom tags work. The important point we were stressing was the question of how it was called, using the "cf_" syntax. Going back to that broader subject, the next issue to consider is where the custom tag will be found when processing occurs.

Where's Waldo?

We mentioned earlier that tags placed in the \cfusion\customtags directory where CF server is installed would be shared, that is, every application on the server would have access to them. And this is true. A custom tag called using this syntax will find a custom tag of the given name, if it exists in the customtags directory.

But it will also look for the tag in any subdirectory of \cfusion\customtags, as well. That can be useful, though the more important benefit of such subdirectories will be explained in the next section.

We had also mentioned that a "local" custom tag could override the shared one, and this is true with this syntax, as well. That is, if the called custom tag is located in the same directory as the caller template, then the code in that local copy of the custom tag is what will be executed.

This can be very valuable when you're perhaps testing a new version of a custom tag. Rather than impact everyone on the server, you can have a testing directory in which your local copy is placed and only that code will see the local copy. Once it's ready for "prime time," it can be moved to the shared customtags directory.

These characteristics of how the custom tag can be found in either a local or shared location are handy, but there are times when either they will be inappropriate (you don't want to allow a local override), inaccurate (you want to execute a specific version of a custom tag in a particular subdirectory of \cfusion\customtags) or insufficient (you want to share a custom tag from templates in more than one directory, but you don't want to or can't place it in the shared customtags directory).

For these situations you may need to turn to yet another alternative for calling custom tags: the CFMODULE tag.

CFMODULE

CFMODULE is another way to call a custom tag that brings all the same benefits as the CF_ approach in terms of passing and returning data, as well as how processing in the caller is placed on hold and output of the custom tag is returned to the caller. The difference, besides the obvious change in tag syntax, is that CFMODULE allows much greater control over exactly where a custom tag is expected to be found. Sometimes you need that control, as we alluded to in the previous section. There are, in fact, two styles of CFMODULE: using the NAME or TEMPLATE attribute. Further, each of these two styles can be used two ways beyond their basic capability.

What's in a NAME?

We could also call our example "format.cfm" custom tag, above, using the following syntax: <CFMODULE NAME="format">

Note that we still refer only to the name of the custom tag, not the ".cfm" extension.

And we could also pass any expected attributes to the custom tag by simply listing them after the call, just as we did with the "cf_" approach. Continuing from our example above, we could call it as: <CFMODULE NAME="format" TEXT="#fname#">

On the surface it may seem as though there's no difference, even that it may take a little more typing to achieve the apparently same result. But there's more here than meets the eye.

A very important aspect of the CFMODULE NAME= approach is that it will not look first in the local directory — that is, the directory where the calling template is located — for the custom tag. It will only look for it in the shared customtags directory. That could seem to be a limitation, but it's actually a benefit if for some reason you want your code to be sure not to execute anything except the shared custom tag, perhaps for security reasons.

There's an interesting and possibly important twist to using the CFMODULE NAME= approach. Used as described, it will search for the tag in the shared customtags directory, and like the CF_ approach it will also look below that directory to any subdirectories under \cfusion\customtags. But one thing that's unique to this approach is that you can name the exact subdirectory of custom tags in which you mean to find the custom tag.

That is, if you prefix the name of the custom tag (within the NAME attribute) with the name of the subdirectory, then only that specific subdirectory's version of the custom tag will be executed. For example, if we had a "salesapps" subdirectory under custom tags, and we placed our format.cfm file in that directory, we could execute that specific version of the custom tag using the following:

<CFMODULE NAME="salesapps.format" TEXT="#fname#">

Notice that all that's changed is the prefix of "salesapps." before the custom tag name. This now forces the template to execute not any local version, not even the version in \cfusion\customtags or any random subdirectory of it, but only format.cfm as it exists in the \cfusion\customtags\salesapps directory.

This can be a useful feature once you understand its purpose. You might use it to organize shared custom tags to designate certain directories for certain departments or application groups (just to make a large number of tags more manageable and keep control under the right groups), or possibly to designate versions in a life cycle/change management paradigm with subdirectory names such as "dev", "qa" and "production".

(As an aside, there's no reason you couldn't use a global variable set in application.cfm to hold the name of the intended directory when executing in a particular mode, such as with <CFSET ctdir="dev">. Then you could use that variable in the call to the custom tag, as in <CFMODULE NAME="#ctdir#.format">. This is perfectly acceptable syntax.)

Finally, the NAME attribute can also specify not just a single subdirectory of the share customtags directory, but even "sub-subdirectories." In other words, if our format.cfm file were stored in a directory called \cfusion\customtags\salesapps\dev\, we could specify <CFMODULE NAME= "salesapp.dev.format">. Notice that each subdirectory is simply specified as another "directoryname." prefix, in just the same order as the directories appear under \cfusion\customtags.

Next time, I'll look at what you can do if you can't place files in the customtags directory, by introducing you to the TEMPLATE= approach.

Ed.Note: The following line under "So...Where to Search?" was left out of the bulleted list in last month's Journeyman column: "Search defusion, cfadvisor, cfdj and other sites."

More Stories By Charlie Arehart

A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor (carehart.org) living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (coldfusionmeetup.com, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science" is responsible for guiding the technology strategy within Hitachi Vantara for IoT and Analytics. Bill brings a balanced business-technology approach that focuses on business outcomes to drive data, analytics and technology decisions that underpin an organization's digital transformation strategy.
DXWorldEXPO LLC, the producer of the world's most influential technology conferences and trade shows has announced the 22nd International CloudEXPO | DXWorldEXPO "Early Bird Registration" is now open. Register for Full Conference "Gold Pass" ▸ Here (Expo Hall ▸ Here)