Vince Bonfanti's Weblog - CFML

Thoughts on CFML tags, CFSCRIPT, Custom Tags and CFML2009

Fri, 10 Jul 2009 06:30:00 -0400

I've been following with some interest the work of the CFML Advisory Committee on the CFML2009 specification, particularly the proposed enhancements to CFSCRIPT. The question of being able to call Custom Tags from CFSCRIPT has helped crystalize thoughts I've been forming for some time regarding the relationship between CFML tags and CFSCRIPT, and how to write better CFML applications. The thing that makes CFML great is its tag-based syntax when used to generate dynamic HTML content. CFML is simply unmatched by any other web application development language in this regard. In fact, you could argue that JSP tag libraries (including the JSP Standard Tag Library) and ASP.NET server controls are nothing more than attempts to mimic CFML tag-based syntax. However, CFML tag-based syntax is awkward and verbose when writing lengthy computational or business logic that isn't generating HTML output. CFML suffers in comparison to other programming languages in this regard. But, this is where CFSCRIPT shines. It's unfortunate that many (most?) people only know about CFML's tag-based syntax and are completely unaware of CFSCRIPT; and, that CFSCRIPT has often been treated as secondary to the tag-based syntax by both CFML developers and CFML server vendors. Conversely, while CFSCRIPT is good for computational or business logic, you would not want to use CFSCRIPT and the writeOutput() function to generate large amounts of HTML content. In summary:

CFML tags. Good (great!) for generating dynamic HTML content. Bad for writing computational or business logic.

CFSCRIPT. Good for writing computational or business logic. Bad for generating dynamic HTML content.

If you accept this view, then the answer to the question of calling Custom Tags from CFSCRIPT is simple: don't do it. Custom Tags are an extension mechanism for CFML tag-based syntax. Custom Tags are intended to generate dynamic HTML content, not to contain computational or business logic. CFSCRIPT should be used for computational or business logic, not to generate HTML content. Calling Custom Tags from CFSCRIPT makes no sense. Following on these thoughts, user-defined functions and components are extension mechanisms for adding computational or business logic to CFML, not for generating HTML content. In retrospect--and I'm not being critical here--the CFFUNCTION and CFCOMPONENT tags were probably a mistake. It might have been better for the CFML language and CFML developers if these features had originally been introduced and/or remained CFSCRIPT-only enhancements. I welcome the proposed enhancements to CFSCRIPT, and have these suggestions for the CFML Advisory Committee and CFML developers:

Don't add support for calling Custom Tags from CFSCRIPT to the CFML2009 specification. If it is added, CFML developers shouldn't use it.

As soon as your favorite CFML server supports CFML2009 and the CFSCRIPT enhancements, ban the use of the CFFUNCTION and CFCOMPONENT tags. Require that user-defined functions and components be implemented using CFSCRIPT.

Immediately ban the use of the writeOutput() function and require that all HTML content be generated using tag-base syntax.

Following these suggestions will take maximum advantage of the respective benefits of CFML tags and CFSCRIPT, and encourage separatation of presentation layer (CFML tags) and business layer (CFSCRIPT) logic within your applications. The result will be better organized CFML applications that are easier to enhance and maintain.

IIS 7.0 Integrated Pipeline and BlueDragon/CFML

Mon, 18 Jun 2007 17:52:00 -0400

The one feature I'm most excited about in Windows Vista and Windows Server 2008 ("Longhorn") is IIS 7.0, the next generation of Microsoft's IIS web server. Starting with this blog entry, I'm going to highlight some of the new features of IIS 7.0 and what they mean for BlueDragon/CFML programmers. To get a good overview of IIS 7.0, you should start by reading the article by Mike Volodarsky in the March 2007 issue of MSDN magazine, entitled, "IIS 7.0: Explore the Web Server for Windows Vista And Beyond." There's also an entire web site devoted to IIS, including extensive information about IIS 7.0, that's well worth checking out. The first new IIS 7.0 feature I want to focus on in this blog entry is the ASP.NET Integrated Request Pipeline. As a CFML programmer, you're already familiar with the concept of a "request pipeline" as implemented by the onRequestStart, onRequest, and onRequestEnd event handlers within Application.cfc. Both IIS and ASP.NET implement similar mechanisms for programmers to access their request pipelines; however, prior to IIS 7.0, the IIS and ASP.NET request pipelines are separate and independent of each other. Further, the Application.cfc events are independent of both of these; the Application.cfc event handlers are only invoked for requests for CFML pages and CFCs. In IIS 7.0, the IIS and ASP.NET request pipelines have been integrated into a single unified runtime. This means that it's now possible for ASP.NET programmers to hook into the full IIS 7.0 request pipeline for all requests: static file, images, and any dynamic content (classic ASP, PHP, etc.) in addition to ASP.NET requests. Here's where it gets exciting for BlueDragon/CFML programmers: because BlueDragon.NET is tightly integrated with ASP.NET, we're able to expose the IIS 7.0 integrated pipeline via existing and new Application.cfc event handlers. With IIS 7.0 and BlueDragon.NET, you'll be able to configure your Application.cfc event handlers to be invoked for any or all requests handled by IIS: static files, images, ASP.NET pages, and any other dynamic content (classic ASP, PHP, etc.). Here's a simplified example that hints as what will be possible. The following onRequestStart event handler is configured to handle all incoming requests for IIS and does two things: (1) it prevents external sites from linking to GIF or JPEG images on this site, returning a "404 Not Found" response instead; and, (2) it prevents external sites from linking anywhere except to the home page ("index.cfm") for this site.

   <cffunction name="onRequestStart" returnType="boolean" output="false">
      <cfargument name="thePage" type="string" required="true">
		
      <cfif findNoCase( cgi.SERVER_NAME, cgi.HTTP_REFERER ) gt 0>
         <!--- referrer is this server --->
         <cfreturn true>
      </cfif>
		
      <!--- referrer is not this server, don't allow image "leeching"
            or "deep" links --->
		
      <cfset var fileExt = right( arguments.thePage, 3 )>
		
      <cfif ( fileExt eq "gif" ) or ( fileExt eq "jpg" )>
         <!--- don't allow image "leeching" --->	
         <cfheader statuscode="404" statustext="Not Found">
         <cfreturn false>
      </cfif>
		
      <cfif ( arguments.thePage neq "/index.cfm" ) and
               ( arguments.thePage neq "/sorry.htm" )>
         <!--- don't allow "deep" links --->
         <cflocation url="/sorry.htm">
         <cfreturn false>
      </cfif>
		
      <cfreturn true>
   </cffunction>

I'll demonstrate the above Application.cfc and discuss it in detail during my keynote at CFUNITED-07. In addition to allowing the existing Application.cfc onRequestStart and onRequestEnd event handlers to be invoked for any request handled by IIS, we're adding the following new Application.cfc event handlers to BlueDragon.NET:

onRequestAuthenticate
onRequestAuthorize
onRequestLog

The events map directly to the AuthenticateRequest, AuthorizeRequest, and LogRequest events in the IIS 7.0 integrated pipeline (they are the same events!), and will be invoked for every request processed by IIS. You can imagine being able to use CFLOGIN to implement an authentication scheme that works for all content on your site, not just CFML pages, or being able to implement custom logging for all types of pages. Our overriding vision is to make CFML a first-class programming language on .NET and Windows--you should be able to do anything in CFML that a C# or Visual Basic programmer can do. Giving CFML programmers access to the IIS 7.0 integrated pipeline is only the first step--I'll talk more about our vision and plans in future blog entries and at CFUNITED-07.

.NET Dynamic Language Runtime (DLR) and BlueDragon/CFML

Fri, 25 May 2007 15:45:00 -0400

Earlier this week I was at Microsoft working with the developers of the .NET Dynamic Language Runtime (DLR) and would like to share what I've learned, what we accomplished, and the potential future impact on BlueDragon and CFML. Scott Guthrie started with an overview of Microsoft's strategy for developer tools and technologies, and an explanation of how the DLR fits into this strategy. He identified three major areas of software application development:

desktop applications (console and GUI-based)
HTML-based web applications
media-based rich Internet applications (RIA)

Microsoft's goal is to provide a common set of technologies and developer/designer tools for building applications in all of these three areas. The common technologies are:

the .NET Framework
Windows Presentation Foundation (WPF)
Silverlight (formerly WPF/e)

The common developer/designer tools are:

Visual Studio (for developers)
Expression Studio (for designers)

Contrast this to the situation that existed prior to the introduction of these technologies and tools. Building Windows desktop applications required using C/C++ and programming to the Win32 APIs. Building HTML-based web applications required use of either ASP, JSP, PHP, or CFML, along with JavaScript. Building RIA applications essentially meant using Flash and ActionScript. Each of these technologies comes with its own set of programming tools, and there's little or no integration among any of the developer tools and tools used by designers. It's the ability to use a common set of technologies and tools to target a variety of application domains that makes Microsoft's strategy so appealing. The goal of the DLR effort is to make sure dynamic languages--such as Python, Ruby, JavaScript, etc.--can participate as first class citizens alongside static languages--such as C#, Visual Basic.NET, etc.--in this overall strategy. Our goal at New Atlanta is to make sure that CFML is one of those dynamic languages. So what did we accomplish in three days? First, we modified the IronPython interactive command-line shell to support a small subset of CFML--just the CFSET and CFOUTPUT tags so far. Here's some sample output (the ">>>" characters are the command-line prompt): This may not look very exciting, but let me explain what's going on here. This isn't a toy example; the CFML parsing is being done by the BlueDragon.NET parser--the very same one in the currently shipping BlueDragon.NET 7.0 product. And, the CFML is not being interpreted--every line is being compiled on-the-fly (dynamically) by the DLR into .NET Intermediate Language (IL) byte code and executed by the .NET runtime. What we're demonstrating here is the ability to hook up the BlueDragon.NET CFML parsing front-end with the DLR code generation back-end to produce a much tighter integration between CFML and the .NET runtime than what's currently provided by BlueDragon.NET. We're not very many steps away from being able to create a Windows console application that looks like this:

<cfcomponent name="Hello">
    <cffunction name="Main">
        <cfset text="Hello, world!">
        <cfoutput>#text#</cfoutput>
    </cffunction>
</cfcomponent>

The idea is that you'll be able to compile the above code into a Windows executable ("Hello.exe") and run it. The result would be exactly equivalent to the following C# code:

using System;


class Hello
{
    static void Main() {
        string text = "Hello, world!";
        Console.WriteLine( text );
    }
}

Add to this the ability to create and invoke .NET objects via CreateObject/CFOBJECT, and you can easily imagine how it'll be possible to create desktop applications in CFML using .NET-based Windows Forms (WinForms). You'll also be able to use CFML to create ASP.NET web applications, and be able to run CFML within Silverlight. Again, this is the goal of Microsoft's strategy: to be able to use the same programming languages, tools, and technologies to create any type of application. What about tools support? By integrating CFML with the DLR, we were also able to demonstrate step debugging within Visual Studio. Here's a screenshot of setting a breakpoint on a CFSET tag: Not bad for three days work! (OK, we cheated--the step debugging was finished on the plane ride home yesterday). We're very excited by the possibilites and promise of a DLR-based implementation of BlueDragon (which, you may notice from the screenshots, we're calling "IronDragon"). CFML will no longer be just about creating HTML-based web applications--though it'll still be great for that, of course--and will be supported as a first-class citizen by Microsoft development tools. Among other topics, I'm going to talk more about IronDragon and provide additional demonstrations during my keynote presentation at CFUNITED-07. I'm also going to be available at our booth to talk about this in more detail, so please stop by and see me if you're interested in learning more.

.NET Dynamic Language Runtime (DLR) on Linux/Mono

Wed, 16 May 2007 20:13:00 -0400

It looks like the Mono developers already have the .NET Dynamic Language Runtime (DLR) and IronPython working on Linux. Very impressive. It'll be interesting to see how long it takes them to get Silverlight working also (it's been promised by the end of this year).

MIX07 - Silverlight and the .NET Dynamic Language Runtime (DLR)

Fri, 11 May 2007 10:35:00 -0400

The big news from last week's MIX07 conference all surrounded Microsoft's new Silverlight browser plug-in for creating rich internet applications (RIA). The two things I'm most excited about are the integrated Common Language Runtime (CLR) within Silverlight 1.1, and the new Dynamic Language Runtime (DLR) for .NET, both announced and demonstrated for the first time at MIX07. More on both of these topics later in this blog entry. While many bloggers and journalists have focused on comparisions between Silverlight and Flash, I honestly don't know enough about Flash--or even Silverlight, yet--to be able to contribute to that discussion from a technical perspective. But based on what I've seen and read so far, if I had to speculate on the market impact of Silverlight, I'd make three guesses:

the majority of people who currently use Flash will probably not flock to Silverlight, but will continue to use the Flash tools and technology they've invested in and are familiar with;
some people who currently use Flash will begin to experiment with Silverlight, but will use Silverlight in addition to Flash, not as a replacement; and,
there are many, many companies and organizations who currently don't use Flash at all, but who will begin to look at Silverlight for RIA development.

The bottom line is I expect to see significant adoption of Silverlight--particularly by Microsoft shops--but not necessarily a diminishing use of Flash as a result. Both Flash and Silverlight are probably here to stay for the long term. Silverlight is a cross-platform, cross-browser plug-in for displaying rich multi-media user interfaces. "Cross-platform" is currently Windows and Mac OS X Intel (not PPC), though there is talk of a non-Microsoft open source implementation for Linux by the same people who created Mono (an implementation of .NET for Linux). "Cross-browser" is currently IE, Firefox, and Safari, and future support for Opera has been announced by Microsoft. At all of the sessions I attended, the presenters made sure to show all of their demos running on both Windows and Mac on a variety of browsers. Silverlight user interfaces are defined in XML files called XAML files. The attributes of XAML files are exposed by Silverlight to JavaScript in the browser. In Silverlight 1.0 (currently in beta), behavior--for example, what happens when a user clicks on an image--is controlled via JavaScript that executes within the browser's scripting engine, not within Silverlight. One nice feature of XAML files is that they can be created by designers using Expression Blend and then opened by developers using Visual Studio to add code and behavior. One of the most important announcements at MIX07 is that Silverlight 1.1 (currently in alpha) includes a cross-platform version of the .NET CLR, which means that behavior can be controlled by .NET code programmed in C#, Visual Basic.NET, or any .NET programming language. Silverlight exposes the HTML DOM to the embedded CLR, so that .NET code running within Silverlight can interact with the DOM (think of being able to write AJAX-style client applications in C# instead of JavaScript). The entire download of Silverlight 1.1, including the CLR, is about 4.2MB. Finally, Microsoft announced the Dynamic Language Runtime (DLR) enhancements to the .NET CLR. These enhancmenents apply to both the "full" desktop/server CLR and the version integrated with Silverlight 1.1. The DLR is derived from work on the IronPython, an implementation of the Python programming language for .NET. The idea of the DLR is to provide a common support layer for implementing dynamic languages on .NET. Microsoft showed demonstrations of IronRuby--an implementation of Ruby for .NET based on the DLR--as well as DLR-based implementations of JScript and Visual Basic. Hmmm...are there any other dynamic langauges that might be candidates for implementation on the DLR? What about CFML? "IronDragon" anyone? What might a DLR-based CFML implementation look like and allow you to do that you can't currently do? Imagine being able to do things like:

compile CFML code into .NET assemblies (.dll)
have CFCs subclass (inherit from) any .NET class written in any .NET language (C#, Visual Basic.NET, IronPython, etc.)
have .NET classes written in any .NET language subclass (inherit from) CFCs
be able to use CFML anywhere you can use C#, Visual Basic.NET, etc., to create any type of .NET-based application
create AJAX-style applications running CFML within the browser (within the CLR integrated within Silverlight 1.1)
have IntelliSense and debugging support for CFML within Visual Studio

We've all heard the phrase "CF is Java" and while I recognize the underlying truth this phrase is intended to convey, I've always been bothered by a fundamental "untruth" in this phrase. CF is not Java in that writing CFML code is not the same as writing Java code. "CF is Java" is basically a marketing phrase that hides as much technical truth as it reveals. It's probably more technically accurate to say "ColdFusion is a Java application" (or, "BlueDragon is a Java application"), but also that "CFML (the programming language) is not Java." With the DLR, I think there's an opportunity to say, "CFML is .NET" and mean it in the fullest sense. There's an opportunity to make CFML a "first class" language for .NET, fully equivalent to and interoperable with C#, Visual Basic.NET, IronPython, IronRuby, JScript, etc. In other words, writing CFML code for .NET would be the same as writing code in any other .NET language. It's this opportunity, along with possibility of running CFML code within the browser (within Silverlight) that has me most excited. I'm going to Redmond the week after next (May 21-23) to work with the DLR team to learn more about what they've done and how we might create a DLR-based CFML implementation. I'll post more information as I learn more, and hopefully we'll even have something to demonstrate at CFUNITED-07. P.S. Here's a must-read blog entry by Scott Guthrie that talks about Silverlight, the embedded CLR, and the DLR in more detail. May 12 UPDATE: after digging through the DLR for the better part of the day today, I'm even more excited about what I think we're going to be able to accomplish, and how quickly. It looks like one additional benefit I hadn't thought about is the ability to create and invoke CFCs from other .NET languages using the native syntax of that language. For example, you'll be able to create CFCs from C# using the "new" operator rather than having to rely on a JavaProxy-like implementation. This illustrates the "deep" level of integration we'll be able to achieve with .NET via the DLR versus current CFML implementations on .NET or Java.

Duck Typing and Performance - Revisited

Wed, 18 Apr 2007 13:34:00 -0400

I finally got some time free to dig into the question of Duck Typing and performance that was originally raised by Sean Corfield's presentation at CFUNITED-06. My goal was to measure the performance effect of Duck Typing on BlueDragon 7.0, and to compare that to the effect on CFMX 7.0.2. But the results really surprised me, to say the least. I downloaded the sample code from Sean's presentation and ran the "performance.cfm" template on CFMX 7.0.2 (after turning on CFTIMER output in Debug Settings). Much to my surprise, I saw no consistent differences between the Typed and Untyped method calls over successive refreshes of the page. In fact, sometimes the Typed calls were faster than the Untyped calls! The differences were usually only a few milliseconds, though sometimes the Untyped calls were up to twice as fast as the Typed calls. Never did I see the "30-40 times" performance advantage of the Untyped calls that others have reported. Then I tried on BlueDragon.NET 7.0. Same results. The timing differences were generally only a few milliseconds, and sometimes the Typed calls were faster. Hmmm... Then I increased the number of iterations from 1000 to 10,000. OK, now I'm seeing some consistent results. On both CFMX and BlueDragon, the Untyped calls are consistently faster than the Typed calls, but not by a whole lot. The Untyped calls generally take only about 75% as long to execute as the Typed calls. For example, in one execution where the Typed calls took 125ms to execute, the Untyped calls took 93ms. That's a 32ms savings (about 26%) over 10,000 method calls--hardly worth getting excited about. Maybe the difference with what others have reported is due to the hardware or operating system. I'm testing on Windows Server 2003. The server hardware is: 3.0GHz dual-CPU Xeon processors with hyperthreading and 1.0GB RAM. That's a pretty beefy machine, but not outrageously so (I'm sure it cost less than $2000--probably closer to $1500). Maybe slower hardware or a different operating system would show different results. Based on these results (and with the usual caveats about "loop 10,000 times" micro-benchmarks), I'd have to agree with Sean's view that Duck Typing is not about performance. In fact, I'd go further and say the question of performance is completely irrelevant to the decision of whether to use Duck Typing or go with a "Java-like" typed approach.

CFUNITED-07: The Future of BlueDragon/CFML

Mon, 16 Apr 2007 15:24:00 -0400

The topic for New Atlanta's keynote at CFUNITED-07 has been posted. From the CFUNITED web site:

With the breakthrough release of BlueDragon 7.0 in March 2007, New Atlanta is now looking towards the future: contemplating, researching, and implementing evolutionary and revolutionary enhancements to BlueDragon and CFML. During this keynote presentation, the company that pioneered CFML innovations such as standard J2EE WAR/EAR deployment, image manipulation (CFIMAGE), .NET integration, and multi-threaded programming (CFTHREAD) offers their vision of the future. This keynote will include demonstrations of near-term BlueDragon enhancements to be delivered in late 2007 and early 2008, as well as a discussion of longer-term research projects that could fundamentally change the way you use CFML.

I wish I could give more details now, but that would take all the fun out of it, wouldn't it? This is one you're not going to want to miss.

CFIMAP and CFZIP tags in BlueDragon

Thu, 05 Apr 2007 07:50:00 -0400

A somtimes overlooked CFML enhancement that BlueDragon added in its very first release in 2002 (gosh, has it really been almost five years?!) is the CFIMAP tag. From the BlueDragon 7.0 CFML Enhancements Guide, Section 4.3.10:

The CFIMAP tag allows you to interact with both IMAP and POP mail servers (CFIMAP may be used instead of CFPOP to interact with POP mail servers). Generally, the sequence of steps to interact with a mail server is:
Open a connection to the mail server (OPEN action).
Get a list of folders from the mail server (LISTALLFOLDERS action).
Get a list of messages within a specific folder (LISTMAIL action).
Perform actions with specific messages (READMAIL, MARKREAD, DELTEMAIL, and MOVEMAIL actions).
Perform actions with folders (DELETEFOLDER and RENAMEFOLDER actions).
Close the connection (CLOSE action).

Another useful pair of tags that were added in BlueDragon 6.0 are CFZIP and CFZIPPARAM, which are used to "create, extract, and list the contents of compressed ZIP files" (Section 4.3.18 of the BlueDragon 7.0 CFML Enhancements Guide). If you need to manipulate ZIP files from CFML, check these out! BlueDragon has been introducing new CFML enhancements in every release since 2002. Some are major and get lots of attention, such as CFIMAGE--which was also introduced by BlueDragon in its first release in 2002--and CFTHREAD and CFC Interfaces that were added in BlueDragon 7.0. Some are less flashy, such as CFIMAP and CFZIP. All are useful. So if you're using BlueDragon, be sure to spend some time reviewing the BlueDragon CFML Enhancements Guide to make sure you're getting the most from your investment.

Mark Drew on CFC Interfaces and CFEclipse

Thu, 01 Feb 2007 17:54:00 -0400

Mark Drew has posted a blog entry that points out another benefit of CFC Interfaces. By using interfaces, your IDE (CFEclipse in this case) can check your CFCs for correctness before your code is ever executed. The earlier you can find and correct errors in your code, the better off you are. As Mark explains, interfaces, along with an IDE that understands them, can allow you to detect errors as you're writing your code.

Why Interfaces in CFML Are Relevant (a Rebuttal to Brandon Harper, Part I)

Sun, 14 Jan 2007 11:42:00 -0400

Last week, Brandon Harper published an article in CFDJ entitled, "Why Interfaces in ColdFusion Are Irrelevant." His article is concise and clearly written, and should definitely be read before continuing here. However, Brandon's article contains a number of factual and logical errors that tend to undermine his conclusions. I would like to offer several rebuttals to his arguments, starting with the central statement of his summary:

"Any implementation of interfaces in the CFML language would essentially only represent a difference in semantics to other ways already available to implement interface-like objects...without providing the safety that interfaces should provide."

I'd like to focus on the first part of this sentence, prior to the "...", which I added. I'll come back later in a follow-up blog entry to address the final part of this statement, as well as other factual and logical errors in his article. (First, as a side note, I believe Brandon is using the word "semantics" incorrectly here. In computer science terms, "syntax" refers to the formal way a concept is expressed in a programming language, "semantics" refers to the meaning of the statement. For example, the following are two different syntaxes for expressing the same semantics in the Java programming language:

i = i + 1; i += 1;

The high-level "semantics" or meaning of these statements is exactly the same--the variable "i" is being incremented by 1--only the syntax is different. So what I think Brandon really meant to say is:

"Any implementation of interfaces in the CFML language would essentially only represent a difference in syntax to other ways already available to implement interface-like objects...without providing the safety that interfaces should provide."

Differences in syntax are sometimes cosmetic and may or may not be meaningful; differences in semantics are always meaningful. I don't think this unintentional misue of "semantics" versus "syntax" takes away from the points Brandon is trying to make in his article.) What Brandon is saying is that support for interfaces in CFML is only "syntactic sugar" that does not have any meaning (semantics) that are different from what can be achieved in other ways using existing CFML programming language syntax. This is factually incorrect in several ways because there are in fact a number of important semantic differences between "true" CFML interfaces as implemented in BlueDragon 7.0 and the "pseudo-interfaces" he describes in his article. The first factual error results from an underlying logical fallacy that's common among CFML programmers, that goes something like this (my words, not Brandon's): "CFML is not compiled, therefore all errors are runtime errors, and all runtime errors are the same". It's true that CFML is not compiled prior to being deployed--that you deploy the "raw" CFML source code and not compiled objects. However, it's also true that both BlueDragon and CFMX use a two-stage "compile-then-execute" technique for rendering CFML pages and CFCs. The results of the "compile" stage are cached in the File Cache so that subsequent renderings of a page only perform the "execute" stage. You can think of this as a sort of "just-in-time" compiling of CFML pages and CFCs; that is, they're not compiled until they're needed. CFML pages are compiled the first time they're requested; CFCs are compiled the first time they're instantiated via CFOBJECT or CreateObject. This "compile-then-execute" process results in two broadly different types of errors that can be detected and reported by BlueDragon and CFMX. The first class of errors are syntax errors; that is, errors made by the programmer that violate the formal syntax specified for CFML tags or functions. Syntax errors are detected during the "compile" stage of page rendering. Consider the following code. My daughter Lindsay's birthday is on January 24 (she turns 21 this year...sigh...). I wrote the following code to send her an mail on her birthday. But this code has a problem; the syntax of the CFMAIL tag requires the TO attribute, which is missing:

<cfif dateCompare( now(), "1/24/2007", "d" ) eq 0>
    <cfmail from="vince@newatlanta.com" subject="Happy Birthday!">
        <cfmailparam file="birthdaygreeting.txt">
    </cfmail>
</cfif>

If you run this code on either BlueDragon or CFMX, you'll get a compile-time syntax error about the missing TO attribute no matter what day it is. That is, the code is not being rendered at compile time, but the entire page is being parsed for syntax errors. Syntax errors are detected regardless of whether the code is going to be executed at runtime or not. So now let's fix the CFMAIL tag to add the TO attribute (sorry, guys, that's not her real email address). Now the code is syntactically correct and will compile successfully on both BlueDragon and CFMX. But what if the "birthdaygreeting.txt" file doesn't exist? When will that produce an error? It will only produce an error when the CFMAILPARAM tag is actually rendered at runtime:

<cfif dateCompare( now(), "1/24/2007", "d" ) eq 0>
    <cfmail from="vince@newatlanta.com" to="lindsay@newatlanta.com"
subject="Happy Birthday!">
        <cfmailparam file="birthdaygreeting.txt">
    </cfmail>
</cfif>

That's the fundamental difference between syntax errors and runtime errors: syntax errors are detected regardless of whether the code is executed, and runtime errors are only detected when (and if) the code is executed. In general, the earlier you can catch an error in your code the better off you are. It's better and easier to catch and fix syntax errors than it is to catch and fix runtime errors. Having established the difference between compile-time syntax errors and runtime errors in CFML, let's see how this applies to interfaces. Here's the pseudo-interface example given by Brandon in his article (note that due to a publishing error, the EXTENDS="Foo" attribute is missing from the Bar.cfc CFCOMPONENT tag and that I've added it here: foobar/Foo.cfc

<cfcomponent hint="Interface for foo">
    <cffunction name="init" returntype="any">
        <return this/>
    </cffunction>

    <cffunction name="implementThis" returntype="any">
        <cfthrow message="foobar.Foo: implementThis() must be implemented">
    </cffunction>
</cfcomponent>

foobar/Bar.cfc

<cfcomponent extends="Foo" hint="Provides foobar functionality">
    <cffunction name="init" returntype="any">
        <return this/>
    </cffunction>

    <cffunction name="implementThis" returntype="any">
        <cfreturn true/>
    </cffunction>
</cfcomponent>

Brandon's point is that if you create a subclass of Foo.cfc but don't override the "implementThis" function, you'll get a runtime error when someone tries to invoke "implementThis", and--in his opinion--that's just as good as interfaces. Well, it's not just as good as interfaces, which is easy to demonstrate if you followed my discussion of compile-time syntax errors versus runtime errors, above. Here's what Brandon's example would look like using interfaces as implemented in BlueDragon 7.0: foobar/Foo.cfc

<cfcomponent type="interface" hint="Interface for foo">
    <cffunction name="implementThis" type="abstract" returntype="any"/>
</cfcomponent>

foobar/Bar.cfc

<cfcomponent implements="Foo" hint="Provides foobar functionality">
    <cffunction name="init" returntype="any">
        <return this/>
    </cffunction>

    <cffunction name="implementThis" returntype="any">
        <cfreturn true/>
    </cffunction>
</cfcomponent>

Now let's assume there's a third CFC, named "Baz", that violates the interface "contract" by not implementing the "implementThis" function. Using Brandon's pseudo-interface technique, Baz.cfc would look like this:

<cfcomponent extends="Foo" hint="Provides foobar functionality"> 
</cfcomponent>

Using BlueDragon 7.0 interface syntax, Baz.cfc would look like this:

<cfcomponent implements="Foo" hint="Provides foobar functionality">
</cfcomponent>

Now let's look at some code that actually tries to use Baz.cfc and figure out when (or if), and what types of error are generated:

<cfset myBaz = createObject( "component", "foobar.Baz" )>
<cfif dateCompare( now(), "1/24/2007", "d" ) eq 0>
    <cfset myBax.implementThis()>
</cfif>

With Brandon's pseudo-interfaces, you'll only get an error is you actually try to invoke the "implementThis" function on an instance of Baz. In BlueDragon 7.0, you'll receive an error as soon as the CreateObject function is executed; that is, when an instance of Baz.cfc is compiled and instantiated. In other words, BlueDragon 7.0 has raised the error checking of interfaces to the level of compile-time syntax errors, which means they'll be easier to find and fix than the runtime errors which may or may not be generated by Brandon's pseudo-interfaces. So getting back to Brandon's central assertion:

"Any implementation of interfaces in the CFML language would essentially only represent a difference in (syntax) to other ways already available to implement interface-like objects..."

We can see that interfaces in CFML in BlueDragon 7.0 represent not just a difference in syntax from Brandon's pseudo-constructor, but have a meaningful semantic difference in when errors are detected and reported by the CFML server engine. There are several other important differences. If Foo.cfc is only intended to serve as an interface, then it should not be possible to create a concrete instance of Foo. That is, the following code should fail, which it will on BlueDragon 7.0:

<cfset myFoo = createObject( "component", "foobar.Foo" )>

However, using Brandon's pseudo-interfaces, the above statement is perfectly legal and you'll only get a runtime error when, or if, you try to invoke the "implementThis" function on an (illegal) instance of Foo. Finally, Brandon's pseudo-interfaces rely on subclassing via the EXTENDS attribute of the CFCOMPONENT tag. The problem will this is that--like Java and C#--CFML only supports single inheritance. This means that using Brandon's pseudo-interfaces you can only "implement" a single interface, and you can't both extend a "regular" CFC and also implement one or more interfaces. All of this is allowed by the syntax of BlueDragon 7.0; for example:

<cfcomponent extends="mySuperClass" implements="interfaceA,interfaceB">
</cfcomponent>

This issue of multiple inheritance or multiple interfaces was brought up on the discussion on Brandon' blog, and the answer some would offer is: "but I don't need multiple inheritance or multiple interfaces--I can just use Duck Typing and Mixins!" Well, my opinions about Duck Typing and Mixins are well-known and don't need repeating here. The kindest thing I can say about Duck Typing and Mixins is that these are new, experimental, and unproven techniques. Whether they prove to be generally useful and become standard practice in the long term remains to be seen. Interfaces, on the other hand, have been proven in over a decade or more of use in developing commercial applications in C++, Java, and C#. (Yes, I know that C++ does not support an "interface" keyword; interfaces in C++ are implemented using abstract base classes that contain only pure virtual functions, and multiple inheritance). I suspect any argument of multiple inheritance (or multiple interfaces) via Duck Typing/Mixins versus BlueDragon 7.0 interfaces would follow pretty much along the same lines as I've discussed above. In conclusion, Brandon's central argument that, "Any implementation of interfaces in the CFML language would essentially only represent a difference in (syntax) to other ways already available to implement interface-like objects...", is wrong on at least three points:

There is an important difference of when errors are detected and reported by the CFML runtime. (BlueDragon 7.0 reports compile-time syntax errors when CFCs are instantiated, which are better than runtime errors that only happen when, or if, you try to invoke a non-implemented interface function).
There is a difference of whether interface CFCs are allowed to be instantiated (this should not be allowed, as in BlueDragon 7.0).
There is a difference in the ability for a CFC to implement multiple interfaces while at the same time preserving the ability to extend a concrete base class (this can only be done in BlueDragon 7.0).

Again, as time permits, I'll tackle what I see as the other flaws in Brandon's arguments, but this pretty much covers his central point. P.S. If you want to know more about the implementation of interfaces and abstract CFCs in BlueDragon 7.0, read the following:

Interfaces and Abstract CFCs in BlueDragon 7.0 Interfaces in Action: the Observer/Event Listener Design Pattern

Mark Anders on strong typing

Tue, 19 Dec 2006 10:01:00 -0400

In a recent blog entry, Ben Forta points to an interview with Mark Anders, a former Microsoft employee, and current Adobe employee and Flex 2 developer. Mark has some interesting (not flattering) things to say about Microsoft, .NET, and WPF, but this comment about strong typing in ActionScript really struck me, considering all the recent debate on this topic within the CFML community:

"One thing I was really happy we could do was come up with a variant of ActionScript that’s strongly typed so you get those good compiler messages. When we moved to ActionScript 3, we had to port all this code and there were a number of places where the programmers said ‘How did we ever ship that? That code just doesn't work’. Once you have real strong typing it ferrets out things you didn't know were there, even if you're a great developer."

In a comment on Ben's blog, Mary Branscombe, the interviewer and author of the article, indicates that Mark had more to say about strong typing. Unfortunately, these additional comments had to be cut from the article due to length constraints. I'd really be interested to know what else Mark had to say on this topic. If strong typing can help even "great developers" find bugs they otherwise missed in their ActionScript code, wouldn't it have the same benefit for CFML developers?

Comparing CFML Server Performance

Tue, 12 Dec 2006 18:56:00 -0400

A few weeks ago Mark Drew wrote a series of blog entries on the topic of performance. In fairness to Mark, he does state more than once that his primary goal was to compare the relative performance of creating structs versus CFCs versus Java objects. However, it's the comparison of various CFML server engines in two of his blog entries that caught many people's eyes, including mine, and that's what I'd like to comment on here. As I commented on one of Mark's blog entries, the type of "loop 10,000 times" style of micro-benchmarks he used in his testing are seriously flawed. It's very difficult to draw any broad conclusions or make meaningful generalizations from the results of such tests. Among the problems with these types of tests are:

Micro-benchmarks can make differences that are small and insignificant seem large and important, to an arbitrary degree. Let's assume the difference between two operations is one-tenth of a millisecond; with 10 iterations the difference is one millisecond--insignificant; with 100 iterations the difference is 10 milliseconds--still no big deal; but with 10,000 iterations the difference is 1,000 milliseconds--whoa, that's a big difference! Want to make the difference seem even larger? Just run more iterations. The question is: how many of these operations do you realistically expect to perform during execution of a single request?
Micro-benchmarks don't reflect real-world applications. They artificially isolate individual operations and don't give you any context about the relative importance of these operations versus what else might be happening when you execute a request. For example, accessing an external resource--such as a database, or web service, or LDAP server, or mail server, etc.--is going to hundreds or thousands of times slower (or more!) than executing any tag or function that doesn't access an external resource.
Micro-benchmarks don't reflect the real-world execution environment. Most developers use single-processor computers (though this has been changing recently), and the micro-benchmarks are usually executed within a single request. In the real-world, most web servers are multi-processor machines, and the most important question is: how does it behave under load? That is, what does the performance look like when executing multiple requests simultaneously?

The bottom line is that micro-benchmarks can cause you to focus on trivial or insignificant items, and can produce misleading results that don't translate into the real-world. Micro-benchmarks are like parking your car in the driveway and revving the engine while it's in neutral to see how fast it'll go. Sure, you can measure the maximum RPMs, which will give some indication of how fast the car might go, but it doesn't tell you what's really going to happen when you put it into gear and head out onto the highway. In order to illustrate these points, we created some tests that we think are more meaningful (but which still have some serious limitations, as I'll discuss below), to see what results we'd get. Basically what we did was modify one of Mark's original tests to remove the nested loops and instead execute the CreateObject function a fixed number of times within a loop:

For completeness, here's what Person.cfc looks like:

Then we used a commercial load testing tool (Microsoft Application Center Test) configured to run three simultaneous clients with no wait time between requests so there were always three requests executing simultaneously. We ran successive test sessions at increments of 100--first 100 CreateObject calls, then 200, then 300, etc., up to 1000--and measured the average response times for one-minute test durations. The test server has dual-CPU 3.0GHz Intel Xeon processors with hyperthreading, 1.0GB of RAM, and is running Windows Server 2003 and IIS 6.0 (that is, it's a pretty typical modern web server). We ran the tests with CFMX 7.0.2, BlueDragon Server JX 6.2.1 and 7.0 beta2, BlueDragon.NET 6.2.1 and 7.0 beta2, and just for fun, last night's developer build of BD JX and BD.NET 7.0 (we've done some performance enhancements in the the month or so since BD 7.0 beta2 was built and I was curious to see how it did). Here are the results, which are quite different from Mark's micro-benchmarks (click to get a larger image): What can we conclude from these results? For one thing, if you relied on Mark's micro-benchmarks to conclude that BlueDragon is slower than CFMX for CreateObject calls, you'd be wrong. However, I'd caution against generalizing too broadly from these results, because these tests contain some (but not all) of the same flaws as the micro-benchmarks. For example, while you may have an application that creates 100, or 500, or even 1000 CFCs via CreateObject, are they really going to be all of the same type? Probably not. And the Person.cfc from Mark's tests is pretty simple--what happens if you're creating CFCs that contains dozens of functions that contain lengthy or complex logic of their own instead of just two simple setters? How will that affect performance? Further, I only had three simultaneous clients running (though with no wait times, this is a higher load that you might think at first). What happens if this is higher? or lower? or if we add wait times? My main point is that the only meaningful performance testing is testing of your application in your production environment under traffic conditions that you reasonably expect to see in the real world. Be skeptical of any artificial performance benchmarks--especially micro-benchmarks--and always look at them with a critical eye with the questions: "How generalizable are these results?" and "How do these results relate to the real world?". There's only one way for you to know which CFML server is the fastest for you and your application: test them yourself. One final point. We do all of our performance testing of BlueDragon on multi-CPU servers using external load testers to generate various levels of traffic. Any claims we make regarding BlueDragon performance are based on these types of tests, and testing of real-world customer applications, and not on micro-benchmarks nor any testing that relies on the server measuring itself (as is typically done with micro-benchmarks).

Interfaces in Action: the Observer/Event Listener Design Pattern

Fri, 27 Oct 2006 17:27:00 -0400

As I began working on a DirectoryWatcher example to demonstrate how the new BlueDragon 7.0 CFTHREAD tag can be used to implement Event Gateways, I realized that this example also presents a great opportunity to demonstrate one use for CFC Interfaces. I'll talk more about the DirectoryWatcher and CFTHREAD in a future blog entry, but would like to focus on its use of CFC Interfaces right now; in the mean time, you can download the DirectoryWatcher code here. The Observer Pattern (which is also known as the Event Listener Pattern, and is sometimes referred to as Publish/Subscribe), is the first pattern discussed in Head First Design Patterns (Freeman), which says (p. 37) that: "The Observer Pattern is one of the most heavily used patterns in the Java Development Kit (JDK), and it's incredibly useful." The Observer is also one of the original patterns described in Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al), which formally introduced the concept of design patterns in software engineering when it was first published in 1995. The basic idea is that some object--known as the Subject or Publisher--is going to produce events or notifications when certain things happen. Other objects--known as Observers or Listeners--can register with the Subject to be notified when these events occur. In fact, you may already be familiar with an implementation of this design pattern in CFML if you use Application.cfc, in which case your Application.cfc is the Listener. The presence of an Application.cfc in a directory is sufficient to register with BlueDragon or CFMX (the Subject) for application event notifications. When an "application start" event happens, for example, your Application.cfc is notified via its onApplicationStart event handler. In the DirectoryWatcher example, the DirectoryWatcher is the Subject; conceptually, you can think of the DirectoryWatcher as watching the entire file system at all times and producing event notifications whenever a file is added, modified, or deleted. You can create a CFC to register with the DirectoryWatcher to receive event notifications for specific directories, and this is where CFC Interfaces come in. First, we need to create a DirectoryWatcher instance; in the example, this is created within the onApplicationStart function of Application.cfc, which is a pretty good place to do it:

  <cfset directoryWatcher=createObject("component","DirectoryWatcher").init()>

Now we need to create a CFC that we can register with the DirectoryWatcher to receive event notifications. But what events does the DirectoryWatcher produce? What functions should our CFC implement and what are the function signatures? Here's the DirectoryWatcher function used to register event listeners:

    <cffunction name="addListener" access="public" returntype="void">
        <cfargument name="directoryPath" type="string" required="true">
        <cfargument name="listener" type="DirectoryListener" required="true">
        ...
    </cffunction>

Hmmm...the second argument to the addListener function is a CFC of type DirectoryListener. That's a clue. Let's take a look at DirectoryListener.cfc:

    <cfcomponent type="interface">
	
        <cffunction name="onAdd" access="public" returntype="void">
            <cfargument name="fileName" type="string" required="true">
            <cfargument name="lastModified" type="date" required="true">
        </cffunction>
	
        <cffunction name="onChange" access="public" returntype="void">
            <cfargument name="fileName" type="string" required="true">
            <cfargument name="lastModified" type="date" required="true">
        </cffunction>
	
        <cffunction name="onDelete" access="public" returntype="void">
            <cfargument name="fileName" type="string" required="true">
        </cffunction>

    </cfcomponent>

That's right--DirectoryListener defines an interface that tells me exactly what event notifications I can receive from the DirectoryWatcher, what functions I need to implement to receive those notifications, and what the function signatures are. I don't want to go into the details of its implementation yet, but in our example, the ImageListener implements the DirectoryListener interface:

    <cfcomponent implements="DirectoryListener">
    ...
    </cfcomponent>

We can now create an ImageListener and register it with the DirectoryWatcher to receive event notifications for any directory (as in the following code, we can register a single ImageListener to receive notifications for multiple directories):

    <cfscript>
    imageListener = createObject( "component", "ImageListener" );
    directoryWatcher.addListener( "C:\temp\images\", imageListener );
    directoryWatcher.addListener( "C:\uploads\images\", imageListener );
    </cfscript>

We're able to pass an ImageListener to the addListener function because it satisfies the contract of that function as specified in the CFARGUMENT tag TYPE="DirectoryListener" attribute: ImageListener implements the DirectoryListener interface. This is what interfaces are for: to define, document, and enforce the contracts between interacting objects and their functions. At this point, my Duck Typing, anti-Interfaces friends might raise an objection: but the DirectoryWatcher example can be implemented without using interfaces! Well, yes, it can (after all, Application.cfc doesn't use interfaces). There are two ways this example could be modified to not use interfaces:

Instead of defining it as an interface, the DirectoryListener can just be a "regular" CFC. Then, the ImageListener would subclass (extend) DirectoryListener and everything will be fine. In some cases this is a reasonable alternative. But there are two drawbacks to this approach:
1. what if ImageListener is already defined to extend some other class? CFCs only support single inheritance, so ImageListener can't extend both DirectoryListener and some other class; this approach is simply more restrictive than necessary; and,
2. ImageListener doesn't actually inherit any behavior (functions) or state (variables) from DirectoryListener, so forcing ImageListener to extend DirectoryListener is really a misuse of subclassing.
Use Duck Typing by changing the second CFARGUMENT of the DirectoryWatcher addListener function to TYPE="ANY", and provide documentation that tells you what functions the event listeners need to implement. This could work, but I prefer the interface-based solution:
1. I like for my CFCs and their functions to be self-documenting; what does TYPE="ANY" in a CFARGUMENT tag tell me? It tells me a lie, really, because in fact it doesn't expect "ANY" argument, it very specifically expects a CFC that implements the onAdd, onChange, and onDelete functions, and my code won't work properly if I give it anything else.
2. I like to have the contracts between my objects enforced as much as possible and as soon as possible by the compiler and runtime. By using interfaces, I'll get an error as soon as I try to pass a CFC that doesn't implement the required functions; by using Duck Typing I'll only get an error when I actually try to call one of the functions and it doesn't exist, if I get any error at all. (Here's an example: imagine I mistype my Application.cfc "onRequestStart" function to be "onReqeustStart"? If Application.cfc had been implemented with interfaces, I'd get an error right away that the onRequestStart function must be implemented; as it stands now, with Duck Typing, all I'll know is that my onRequestStart function isn't getting called, and now I'm off digging trying to figure out why).

This is a very simple example of the usefulness of CFC Interfaces when implementing the Observer/Event Listener design pattern (which you'll want to do whenever you implement asynchronous gateway-type features using CFTHREAD). I'm going to follow-up with a detailed look at the DirectoryWatcher example, focusing on its use of CFTHREAD. Then I'll see if I can follow-up with some more detailed interface examples, and a few examples for Abstract CFCs (here's a hint: nearly all of the design patterns in the books referenced above are based on interfaces or abstract classes, or both; Singleton is the only pattern I can find that doesn't require either).

Interfaces and Abstract CFCs in BlueDragon 7.0

Mon, 23 Oct 2006 14:14:00 -0400

With all of the discussion lately about interfaces and whether they should or shouldn't be included in CFML, no one's ever really described what interfaces are or how they're used. The discussion has all been theoretical. Worse, no one's talked at all about abstract CFCs, which are just as important as--or maybe even more important than--interfaces when doing object-oriented programming. I thought I'd remedy this situation by starting with a description of interfaces and abstract CFCs as implemented in BlueDragon 7.0, and then following with a series of blog entries that demonstrate practical uses of these concepts in developing real, useful CFML programs. First, I must stress three things about these new features in BlueDragon 7.0: (1) their use is completely optional; if you don't understand them or don't think they're useful to you, then you don't have to use them; (2) they don't take away any of the dynamic programming features that exist in CFML; they don't "limit" or "restrict" you in any way; and, (3) they're completely backwards-compatible; any CFC code that runs today on CFMX or earlier versions of BlueDragon will continue to run unmodified on BlueDragon 7.0. The following is taken from the What's New in BlueDragon 7.0 document: Interfaces and abstract classes are common and useful features of most object-oriented programming languages such as C++, Java, and C#. BlueDragon 7.0 introduces these features for CFCs. If you’re familiar with these concepts, then their implementation in BlueDragon 7.0 should be straightforward and easy to understand. If the concepts of interfaces and abstract classes are new to you, it helps to begin by understanding abstract functions. An abstract function is a function that does not (and cannot) implement a function body. In BlueDragon 7.0, a function can be declared to be abstract using the new TYPE attribute of the CFFUNCTION tag:

<cffunction name="myAbstractFunction" type="abstract"/>

Abstract functions can only be declared within CFCs; that is, you cannot declare abstract user-defined functions within CFML pages. The body of an abstract function may only contain CFARGUMENT tags; if it contains any other tags an exception is thrown. A CFC that contains one or more abstract functions must be declared to be abstract using the new TYPE attribute of the CFCOMPONENT tag (an "abstract CFC"):

<cfcomponent type="abstract">
    <cffunction name="myConcreteFunction">
        <cfreturn "I have an implementation, so I'm concrete"/>
    </cffunction>
    <cffunction name="myAbstractFunction" type="abstract"/>
    ...
</cfcomponent>

You may not create an instance of an abstract CFC using CFOBJECT, CreateObject, or CFINVOKE. Abstract CFCs may only be used as base classes for other CFCs (that is, other CFCs may extend abstract CFCs). If a CFC extends an abstract CFC, the subclass CFC must implement all of the abstract functions declared by the abstract superclass CFC, or the subclass CFC must itself be decared abstract. If a CFC contains only abstract functions, it may be declared to be an interface using the new TYPE attribute of the CFCOMPONENT tag (an "interface CFC", or just "interface"):

<cfcomponent type="interface">
    <cffunction name="abstractFunctionOne" type="abstract"/>
    <cffunction name="abstractFunctionTwo" type="abstract"/>
    <cffunction name="abstractFunctionThree"/>
    ...
</cfcomponent>

Because an interface CFC may only contain abstract functions, you can omit the type="abstract" declaration for its CFFUNCTION tags. Like abstract CFCs, you cannot create an instance of an interface CFC. An interface CFC may extend another interface CFC, but may not extend an abstract CFC or concrete ("regular") CFC. CFCs may declare that they implement one or more interface CFCs using the new IMPLEMENTS attribute of the CFCOMPONENT tag. A CFC may implement multiple interfaces by declaring them as a comma-separated list:

<cfcomponent implements="interfaceOne, interfaceTwo"
        extends="mySuperClass">
    ...
</cfcomponent>

A CFC must implement all of the abstract functions declared by all of the interfaces declared in its IMPLEMENTS attribute. An abstract CFC or interface CFC may be specified as the TYPE attribute for CFARGUMENT, or RETURNTYPE attribute for CFFUNCTION.

Query caching with CFQUERYPARAM and CFSTOREDPROC

Mon, 11 Sep 2006 11:44:00 -0400

Most CFML developers are aware that you can't use query caching in CF5/MX with the CFQUERYPARAM or CFSTOREDPROC tags. You should be aware that these limitations don't exist with BlueDragon, so after you've upgraded to to either the Java/J2EE or .NET editions of BlueDragon you're free to use query caching with these tags. CORRECTION: query caching does not work with CFSTOREDPROC, but it does work with CFQUERYPARAM within CFQUERY.