You've probably been told for years that CFINCLUDE is like a compile-time directive that "pulls code" from another file into your template for reuse. That's wrong. I'll prove it to you. Indeed, have you ever tried to include something other than a CF template? You can. Wonder what including a text or XML file might do?

If you're reusing CFML code, have you ever wished you could reuse a template and have its associated Application.cfm be executed? You can. Not with CFINCLUDE, though. In fact, did you know there are at least 13 ways to reuse code? It's not just CFINCLUDE, custom tags, Application.cfm, and CFLOCATION anymore. (Why do I consider CFLOCATION a means of reuse? I'll discuss this later.)

In this article, we'll see these magical secret powers of includes, some of which apply to CFMX only, some that apply to CF4 and 5, and some that are in BlueDragon only. But the first two assertions above, about whether CFINCLUDE is a compile-time directive and includes other than CF templates, are really not new at all. You may have been laboring under false presumptions for years.

CFINCLUDE As Code Include
I'm willing to bet that you've always been told (and simply accepted) that CFINCLUDE's job was to pull code in from another template for reuse. A classic example may be reuse of headers and footers. You define the needed HTML tags for the header in something like header.cfm, and use it in your template with CFINCLUDE TEMPLATE="header.cfm". The result is that the header appears at the top of the page. Simple, right? Of course, the beauty is that if you ever need to change the included file, you change it once and all files that include it will be effected immediately.

You probably also know that if you wanted to use variables in both the including and included templates, you needed to be careful because they shared variable scopes. Let's assume we have main.cfm that uses CFINCLUDE TEMPLATE="included.cfm". If you set a variable in main.cfm, its value is seen in included.cfm and vice versa. It's important to understand that because if you aren't careful, you might change the value of a variable in included.cfm and not realize it will "flow back" into main.cfm, where the output will be "Sally" (see Figure 1).

 

Most programmers know these things and just accept them as gospel. And it gives all the more credence to the notion that CFINCLUDE "pulls the code" of included.cfm into main.cfm, and then interprets/compiles main.cfm. Indeed, the very notion of "include" files is common in other languages (such as C's #include) and they work just that way, so it's natural to assume they would do so in CFML.

But CFML's include is different. Need proof? For one thing, if it was a "compile-time" directive, you could open a tag in the calling template and close it in the included template. But that's not possible.

Still further proof that it's not a compile-time directive is that if you change the included file, the including file (main.cfm, above) would have to be recompiled to see the changes. That's not what happens.

Indeed, now that CFMX creates compiled Java classes, you can see that for yourself. Look at the list of Java classes created by CFMX (in cfusionmx\wwwroot\WEB-INF\cfclasses). Using Windows Explorer or My Computer (on a Windows machine), sort the list by Modified Date so that the most recent dates are at the top of the list. If you just created the two templates above, and ran them, their corresponding class files would be listed first. (The mapping of CF template names to Java class names in CFMX is beyond the scope of this article.)

The important point to note, however, is that if you change the included file (included.cfm in our example) and run the calling program (main.cfm), you'll see that while the underlying class file for included.cfm is updated, that for the calling file is not. This shows that CFINCLUDE is a runtime - not a compile-time - directive. And the same was true in CF 4 and 5 (and BlueDragon).

Still further proof lies in the fact that you can set the included template name dynamically. "What?" you may exclaim. The TEMPLATE attribute can be a variable? Yes. Try it.

CFINCLUDE As Output Grabber
So what's really happening? It may shock some to learn that CFINCLUDE really works much like a custom tag. Not quite, but perhaps very differently than you've been led to believe. What you get when you CFINCLUDE a template is shared access to the processing of the template (creation of variables, etc.) and the output of that template. It may feel like "inclusion of source code" but it's not, really. That's quite a surprise for many, I'm sure.

But here's something that may surprise many. If you carry this observation (that CFINCLUDE grabs output) to its logical conclusion, then it would seem reasonable that you could use it to pull in more than just CFML. Indeed, even that very phrase prolongs the incorrect assertion. You're not "pulling in" CFML. You're executing it and inserting the output of the named file at the given point in the program. But what if it's not CFML that you're including?

Could you CFINCLUDE an XML file? Sure! Again, it's not about inserting the "code" of that included file, just its output. The only question is whether it makes sense to "include" such a file. But clearly, the notion of CFINCLUDE being just a means to "reuse CFML code" is a limited one.

Some files you include won't display properly unless the MIME type of the page has been set correctly for the given file. And you may want to turn off debugging and any other white-space generating aspects of your CFML page. Here's an example:

<cfsetting showdebugoutput="No">
<cfcontent type="text/plain">
<cfinclude template="test.xml">

If you have trouble seeing the output in Internet Explorer, try sending it to Netscape instead. IE tries to render the XML using a built-in stylesheet. If the output isn't pure XML (as if there are CFML errors being rendered as HTML on the page), IE won't show the page at all.

CFINCLUDE As Content Sender
If you could include an XML document this way, then clearly CFINCLUDE is more than just for code. How about a CFINCLUDE of a PDF file? Will that work? What will happen? Sure it will work, if you preface it with <CFCONTENT TYPE="application/pdf">, in order to set the MIME type. And if the browser is set up for PDF, the document will open in the reader.

That may blow away some who have struggled with (or been prevented from using) CFCONTENT as the means to send the file as well as set the MIME type. (Indeed, I've long felt that while the use of CFCONTENT's FILE attribute should be restricted for security reasons, the TYPE attribute when used alone shouldn't at all.) This does beg the question of when you would choose one over the other.

There is at least one difference between the two: CFCONTENT's FILE attribute accepts a full path (drive letter/directory/file) whereas CFINCLUDE's TEMPLATE attribute permits only a relative path (or can leverage an Administrator mapping). Also, CFCONTENT allows specification of the MIME type in the tag itself, and it stops processing of the page. Clearly CFCONTENT has its purpose. But if you don't need either of those benefits and are precluded from using CFCONTENT, CFINCLUDE is an interesting alternative.

Does the ability to use CFINCLUDE in a similar way open the door to a security issue? If you presume that locking down CFCONTENT locked down any way to "send" files to the browser, I suppose so. Just remember that with both, it's only an exploit for someone able to create CFML code on the server.

CFINCLUDE As File Reader
Here's another interesting twist: What if you used it to read in a text file, surrounding it with CFSAVECONTENT? Would that be the same as CFFILE ACTION="read". Yep. Here's an example, assuming you want to read in a file called test.txt:

<CFSAVECONTENT VARIABLE="input">
<CFINCLUDE TEMPLATE="test.txt">
</CFSAVECONTENT>

<CFOUTPUT>#input#</CFOUTPUT>

Again, this may trouble those who've locked down CFFILE as the only means to read in a file. Of course, there are still other ways to read in files, using CFHTTP and Java classes, so this may not be as big a deal from a security standpoint. But it may still surprise many. Now do you see why I titled the article as I did?

Processing Application.cfm on Include
There's one aspect of CFINCLUDE, and indeed custom tags, that has long bothered some. Well, some may like how it works, while others likely haven't even noticed.

When you CFINCLUDE code or call a CF custom tag, have you ever wished that the included/called template would execute just like a full-fledged CF template, at least with respect to executing any associated Application.cfm (and optional OnRequestEnd.cfm)?

Again, to some this would seem lunacy to want it. But just know that there are cases when it's been desirable. But CFINCLUDE doesn't work that way, nor do custom tags. The closest you could come was using CFHTTP (or CFLOCATION, if you didn't mind changing pages) to cause the user to see the full-fledged output of one template from another.

Am I going to tell you that you can make CFINCLUDE work differently? No. (Though I will point out in a moment that BlueDragon does indeed offer that option.)

What I'll point out first is that there's a little-known fact about one of the new features in CFMX, which some may still not yet know exists, called getpagecontext().include().

If you read the CFMX docs (particularly Chapter 32 of the "Developing CFMX Applications with CFML" manual), you'll learn that this "function" is used to include the output of JSP pages within CFML. I say "function" because the format of the syntax is unlike anything we've ever had in CFML. The closing parens at the end of getpagecontext surround nothing, and the ".include()" that follows takes as its argument the JSP page to be included, as in getpagecontext().include("mypage.jsp").

But this isn't just a curious alternative format, nor is it just for calling JSP pages. It can call CFML templates as well. More important, this form has the unique characteristic of causing the included file to really be processed just like a full-fledged page - and yes, with any Application.cfm (and optional OnRequestEnd.cfm) that would be executed if you browsed the template directly.

This is a staggering discovery for those who need that solution. If you ever catch yourself using CFHTTP against a local file just to get the output of a page because you want it executed "fully" but have its output included inside another page, this is the solution for you. And who knows what other problems may exist for which this may be the solution. Please drop me a line to let me know.

BlueDragon, an alternative platform for running CFML applications, does add a couple of things to make your life easier with respect to this discussion. The new include functionality for processing Application.cfm, discussed above, comes as a benefit of the underlying J2EE server on which CFMX runs. And like CFMX, BlueDragon is also built on the J2EE platform. Indeed, while it doesn't yet support most CFMX tags, BlueDragon does offer Java-based features like this as well as J2EE sessions, the ability for JSP pages to exist alongside your CFML templates, and the ability to integrate with Java in many of the same ways that CFMX can.

And with respect to this discussion of includes, it also adds a couple of things to make your life easier (and they're different from CFMX because they were added to BlueDragon before CFMX came out).

Similarly, while there is an available getpagecontext().forward() in CFMX for server-side redirection (as I discussed in the June 2002 CFDJ article, "New Possibility in CFMX: Server-Side Redirects"), BlueDragon offers the simpler CFFORWARD. This is quite different from CFLOCATION and an important new tool for many applications. But it's the same concept as CFMX's approach. Indeed, to use Java/OO terminology, it's the same "implementation," but a different "interface". Again, New Atlanta had theirs first and it seems MM just didn't think of it. There are just a few such differences where New Atlanta has decided to innovate rather than wait.

While the forward approaches and CFLOCATION may seem more about redirecting control in a program, the fact is that they can be key to reuse of code when designing to the Model-View-Controller paradigm.

13 Ways to Reuse
That leads nicely to the last point I had raised at the beginning: that there are now 13 ways to reuse code in CFML. The traditional ones from CF 4 and 5 and on into MX (and of course BlueDragon) are CFINCLUDE, custom tags, CFMODULE (admittedly, just another way to call custom tags versus the CF_approach), Application.cfm, OnRequestEnd.cfm, CFLOCATION, and CFSCRIPT-based UDFs.

CFMX adds getpagecontext.include() and getpagecontext.forward() as well as CFCs and CFFUNCTION, while BlueDragon adds CFINCLUDE PAGE and CFFORWARD. New Atlanta has committed to supporting CFMX tags and functions in its Release 4 version, due later this year. And who knows, perhaps we'll see CFFORWARD and CFINCLUDE PAGE showing up in CFMX some day. That's one of the great things about competition.

You might even add CFX custom tags to the list of code reuse options, but those don't allow reuse of CFML code or other Web content, which is clearly the focus of this article.

Summary
In any case, whether you use CFMX, CF 4 or 5, or have made the move to BlueDragon, I hope you've learned a lot from this article.

We learned that CFINCLUDE is much more than just a way to "pull in code". It opens doors to interesting similarities to CFCONTENT and CFFILE. And we learned that while CFINCLUDE can't call upon an included page to execute its associated Application.cfm, the new J2EE-based variants in both CFMX and BlueDragon can.

There are certainly a lot of surprises in the secret powers of includes. I hope this may open the doors to some very interesting new application development possibilities. Again, please let me know if it does.