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.

Over the past few months we've been exploring various ways to integrate BlueDragon/CFML with Microsoft's ASP.NET AJAX framework. One of the most interesting things we've come up with is the CFUPDATEPANEL tag to support partial page rendering. The idea is that any time you have a page that's updated based on an HTML form submission, instead of re-rendering the entire page simply wrap the portion of the page that's to be updated within a CFUPDATEPANEL tag. The body of the CFUPDATEPANEL tag--which can contain *any* server-side CFML code--is the only portion of the page that's re-rendered when the form is submitted.

Here's a trivial example that demonstrates CFUPDATEPANEL; the following page displays the current time and then updates it whenever the "update time" button is clicked:

<h3>Start Time: <cfoutput>#timeformat(now(),"long")#</cfoutput></h3>
<cfform>
    <cfupdatepanel>
        <p><cfoutput>#timeformat(now(),"long")#</cfoutput><br>
        <input type="submit" value="update time">
    </cfupdatepanel>
</cfform>

As you run the live demo, notice that every time you click the "update time" button, the time displayed within the form is updated, but the "Start Time" displayed in the page header is not, indicating that only part of the page was updated. Note also that--as is typical with AJAX applications--there's no "page flicker" as the time is updated.

The CFUPDATEPANEL tag also supports a REFRESH attribute to allow the partial page content to be updated automatically, without requiring a form submission. Again, here's a trivial example that demonstrates this feature; the following page has the contents of the CFUPDATEPANEL updated every 1000 milliseconds (1 second):

<h3>Start Time: <cfoutput>#timeformat(now(),"long")#</cfoutput></h3>
<cfform>
    <cfupdatepanel refresh="1000">
        <p><cfoutput>#timeformat(now(),"long")#</cfoutput><br>
    </cfupdatepanel>
</cfform>

Again, as you run the live demo, notice how smoothly the time is updated, without any corresponding page flicker.

Now let's take a look at a more complicated example to really demonstrate the power of CFUPDATEPANEL (and also introduce the associated CFUPDATEPROGRESS tag). First, consider this example taken from Chapter 24 of the ColdFusion Web Application Construction Kit. As you run the live demo, note the behavior that's typical of non-AJAX pages: there's a noticeable flicker as the entire page is refreshed every time you click a "Next" or "Back" link, and the URL in the browser's address bar is updated with the new query parameters being used to control which records get displayed. Notice also that the timestamp at the bottom of the page is updated each time, indicating that the entire page was updated. Here's the source code for this page (we'll use this to compare to the CFUPDATEPANEL-based version):

• NextN2.cfm
• NextNIncludeBackNext.cfm

Here's the same example modified to do partial page rendering using the CFUPDATEPANEL tag. As you run the live demo, note the differences with the original: there's no flicker as the page contents are smoothly updated, the URL address bar in the browser doesn't change, and the timestamp at the bottom of the page doesn't change (showing that this was indeed only a partial page update). Here's the source code for the CFUPDATEPANEL version:

• NextN2.cfm
• NextNIncludeBackNext.cfm

The changes required to modify the original example to create the AJAX-based version were:

1. Modified NextN2.cfm to add the CFFORM and CFUPDATEPANEL tags; and,

2. Modified NextNIncludeBackNext.cfm to invoke the __doPostBack() JavaScript function when the "Next" or "Back" link is clicked.

That's it! That's how easy it can be to use the CFUPDATEPANEL tag to turn existing pages into AJAX-enabled pages that do partial page rendering. There are more complicated scenarios we're working on, and also a way to hide the __doPostBack() JavaScript call, but the idea is that it should be this easy to add AJAX capabilities to existing pages, just by adding new server-side CFML tags, and without worrying about writing any client-side JavaScript code.

There's one more example to look at. We've also implemented a CFUPDATEPROGRESS tag that works in conjunction with CFUPDATEPANEL to automatically display progress indicators when the page is being updated. Again, run the live demo to see this in action. Here's how the CFUPDATEPROGRESS tag is used:

<cfupdatepanel name="NextN2">
    .
    .
    .
    <cfupdateprogress for="NextN2" delay="0">
        <table cellspacing=0 cellpadding=2><tr><td bgcolor="red">
        <font size="-1" color="white">
         Loading new records... 
        </font></td></tr></table>
    </cfupdateprogress>
</cfupatepanel>

Notice that the FOR attribute associates the CFUPDATEPROGRESS tag with a CFUPDATEPANEL tag (there can be multiple CFUPDATEPANEL tags on a page). Also note the DELAY attribute; the body of the CFUPDATEPROGRESS tag is only displayed if it takes longer than this amount of time (in milliseconds) for the associated CFUPDATEPANEL tag to update the page. The default value for the DELAY attribute is 500 milliseconds (I set it to 0 for this example so it would be more obvious).

Finally, it's worth mentioning that the Microsoft ASP.NET AJAX client libraries on which CFUPDATEPANEL and CFUPDATEPROGRESS are based are free, open source, cross-browser and cross-platform. I've tested these examples on IE and Firefox on Windows, and on Firefox on Linux. I'd be interested to know what other browsers and operating systems people use to run these examples (add a quick comment, if you don't mind), and if you see any problems with your preferred browser or operating system.

Also, these examples are being served by BlueDragon.NET, but we're planning to get CFUPDATEPANEL and CFUPDATEPROGRESS working on the Java/J2EE editions of BlueDragon as well.

This is exciting stuff, and is only the beginning of some pretty cool things we're going to be able to accomplish by building on some of the great technology Microsoft is creating. Come to my keynote at CFUNITED-07 if you'd like to hear more, or stop by to talk to me at our booth (the best time to catch me will be Thursday afternoon after the keynote).

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.

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.

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).

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:

1. 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;
2. 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,
3. 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.

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.

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.

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:

1. Open a connection to the mail server (OPEN action).

2. Get a list of folders from the mail server (LISTALLFOLDERS action).

3. Get a list of messages within a specific folder (LISTMAIL action).

4. Perform actions with specific messages (READMAIL, MARKREAD, DELTEMAIL, and MOVEMAIL actions).

5. Perform actions with folders (DELETEFOLDER and RENAMEFOLDER actions).

6. 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 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.