devxlogo

Build a Better ColdFusion Cache Tag

Build a Better ColdFusion Cache Tag

aching is an essential strategy for improving the performance of your applications, and ColdFusion offers much pre-packaged functionality to assist in this area, including a number of application server caching settings in the ColdFusion Administrator. ColdFusion also offers caching options directly through ColdFusion tags. For example, developers can use the tag’s cachedAfter and cachedWithin settings to cache the results of database queries and the tag for its direct support of user-interface caching.

The tag is not without its limitations, however. It works very well when you want to cache a whole HTML page, but if you want to cache just part of a page, you are out of luck. The “page” is the smallest unit that can process. Such a restriction might be reasonable for simple applications, but almost any sophisticated application design uses some kind of templating system to assemble complex interfaces from a variety of individual ColdFusion scripts. As such, most modern application designs don’t allow whole pages to be cached since to do so requires a single script to serve as the root point for the whole application.

Many ColdFusion frameworks, like the popular Fusebox or the newer Mach-II, require that all traffic go through the same ColdFusion script (usually named something like index.cfm). If you place a tag on this page, only the first page accessed ever gets displayed.

Luckily, it’s quite easy to write a cache tag that can work with sections of pages, and this article describes a script that does just that. The tag is named CacheOMatic (click here to download it), so the first step is to create a file called CacheOMatic.cfm and save it to a directory where ColdFusion custom tags are stored (the paths indicated under the setting “Custom Tag Paths” in the ColdFusion Administrator, generally a default path that looks something like C:CFusionMXCustomTags).

When you want to cache a section of a page, you surround it with the tag , as in:

Here's some stuff to cache!

While you want to support a plain vanilla version of the tag, you also will add some optional parameters. The CacheOMatic tag will take the three inputs shown in Table 1, all optional.

Name The “Key” of the Cache
scope The scope in which you want to store this data; corresponds with ColdFusion scopes: application, session, and server
exp How long until the cache expires
Table 1. Optional Inputs for CacheOMatic

Verify Values
Your first step is to check for each of the inputs in Table 1 and supply some default values for the ones that are missing. To do this, use the tag:

If the name is missing, compose the tag name from the script name and the query string. For the expiration, use the same syntax used in ColdFusion datetime functions (which means that ‘m’ means “months” not “minutes”?’n’ indicates minutes, so be careful). By default, the expiration is set to “1,h”, which translates to one hour.

The next attribute tells ColdFusion where to cache the data:

By default, the cache is for the whole application, though you can also make the cache unique to a server (“server”) or even to an individual client (“session”). Setting the scope to “session” should be done with caution, however, as storing lots of data in the session scope can consume lots of memory. Do it only when it is safe and the tradeoffs are clear.

To simplify the code, create a pointer to the given scope and parse out the expiration information:

As for the actual data, store it in a ColdFusion struct, with the various items in the cache keyed to the “key” parameter above, and store the expiration data in a second struct. First, check whether these structs exist, and create them if not:

		

Now you do the actual caching work. The code is actually quite short. The outer if/then structure, which can be a bit confusing, looks like this:

		

Custom Tags execute twice: once for the starting tag and once for the ending tag. This structure executes the top set of statements when the first tag is read (), then executes the final statements when reading the end tag (). So at the end of each tag execution, you save the “stuff” inside the tag to the data struct and save an expiration for it to the expiration date struct.

Now the code inside the first tag is where you actually check to see if you should use cached data or not:

													#ptr.CacheOMatic[Attributes.key]#						

This algorithm is fairly straightforward, and it goes like this:

	If you have data in the cache for the key
Get the expiration date for the data
If the expiration date is greater than the current date
Output the data in the cache and exit this tag

Note that if you exit the tag by calling , the code inside the CacheOMatic tag will never run. This is the work you save if the cached data is not stale. If the data is stale, you allow the whole tag to execute.

To test the tag, create a minimal ColdFusion script as follows:
#Now()#
#Now()#

When you hit this page with your browser, you should see a page with two dates. If you keep refreshing, the first date will update after 20 seconds (hence, the expiration “20,s”), while the second date updates after one minute (“1,n”). Your cache tag is complete.

A Simple Performance Boost
Not all scripts can be cached, of course. For expensive database transaction code or other time-consuming ColdFusion code that does not need to be executed with every request, however, you now have an elegant and simple solution. Not bad for about 30 lines of code.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist