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.

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.