Early Bird registration pricing for CFUNITED Europe 2008 ends on January 10. Register before then and save $100. There's also a group discount rate available--register 3 for the price of 2--contact info@cfunited.com for details.

I will be presenting IIS 7.0 for CFML Developers at this year's inaugural event.

It seems my keynote went pretty well this morning--I received a lot of positive feedback. For those who requested it, here are my presentation slides.

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

As a follow-up to yesterday's blog entry where I discussed how we're integrating BlueDragon with the new IIS 7.0 configuration system, I'd like to take a look at the new IIS Manager and how it will affect BlueDragon/CFML developers and server administrators. There are three key points I want to make:

1. BlueDragon administration and configuration is fully integrated with IIS 7.0 and ASP.NET.

2. BlueDragon administration and configuration can be done globally, and per individual web site and web application.

3. The new IIS 7.0 administration and configuration system allows very fine-grained control of delegation of permissions by the server administration to individual web site and web application administrators.

4. The new IIS 7.0 Manager supports remote access to the server by individual web site and web application administrators, with feature delegation controlled by the server administrator.

Let's take a look at the new IIS Manager (this screenshot if from Windows Server 2008 beta3; a screenshot from Windows Vista would be similar):

Click for a larger image

The first thing you'll notice--if you're familiar with earlier versions of IIS--is that you're now presented with a collection of "applets" to edit various configuration settings, rather than a tabbed properties dialog; this makes it much easier to navigate and find exactly the configuration settings you're looking for. You'll also notice that ASP.NET settings are included, and that we've added BlueDragon configuration directly into the IIS Manager (those are generic icons for now, we have a graphics artist working on a nice set that will match the others). Here's a screenshot of the BlueDragon application settings page:

Click for a larger image

Note that the configuration is heierarchical; in the above screenshot, we're editing the global configuation. The is indicated by the fact that the server is selected in the left pane and in the address bar; note also the the status indicator in the lower left (circled in red) showing that it's the global applicationHost.config file that's being edited (see yesterday's blog entry for a discussion of applicationHost.config).

Contrast the above screenshot with the one below. In this screenshot we're editing the settings for the Default Web Site, which is selected in the left panel and in the address bar, and note that it's the Default Web Site's web.config file that being edited (circled in red at the lower left):

Click for a larger image

Now let's take a look at feature delegation, which can only be done at the global server level, and only by a server administrator. Feature delegation is used in conjunction with remote access to specify which features an individual web site or web application administrator is allowed to modify. Note in the following screenshot that all of the BlueDragon features are configured as "Read/Write", meaning that any BlueDragon configuration settings can be modified for any web site or web application:

Click for a larger image

Modifying any BlueDragon feature to be "Read Only" prevents that feature from being modified for any web site or web application. It's possible to provide finer-grained control by marking a feature "Read Only" only for particular web sites or web applications, and "Read/Write" for others. It's even possible to mark individual settings within a feature as "Read Only" while leaving others "Read/Write". For example, within the BlueDragon application settings page, you can mark the "Buffer Entire Page" option as "Read Only" while leaving the other settings "Read/Write".

It's difficult to explain all of this thoroughly in a short blog entry, but hopefully I've given you a sense of what's possible. I'm going to go over all of this in more detail at my keynote at CFUNITED-07, so be sure to attend if you'd like to hear more. Also, visit the IIS web site for more information on IIS 7.0 administration and management.

In yesterday's blog entry I discussed the IIS 7.0 integrated request pipeline and the new capabilities we'll be able to provide to BlueDragon/CFML programmers. Today I'd like to take a look at the new IIS 7.0 configuration system and the benefits it will bring to both developers and server administrators when configuring and deploying CFML applications.

The key characteristics of the new IIS 7.0 configuration system are:

• Configuration settings are stored in clear-text XML files--no more metabase.

• All IIS and ASP.NET configuration settings are stored in the same XML files.

• The configuration schema is extensible so that third-party applications--such as BlueDragon--can also store configuration settings in the same XML files alongside IIS and ASP.NET.

• The configuration files are hierarchical, with a single global configuration file that defines the default configuration settings for the server, and website- and application-level configuration files that can override or extend the global defaults.

• The server administrator can decide which features can be overridden by website- and application-level configuration files, and which are locked and cannot be overridden.

So what does all this mean, especially for BlueDragon/CFML developers and administrators? The first thing to realize is that every IIS web site and web application automatically contains a separate BlueDragon.NET instance with its own separate configuration settings. This means you can configure datasources, mappings, custom tag paths, etc., and have them apply only to a single web site or individual web application within a web site. Let's take a look at a practical example of how this can be useful.

The global IIS 7.0 configuration is stored in the following file, which can only be accessed by Windows users with administrative privileges:

C:\Windows\System32\inetsrv\config\applicationHost.config

Let's assume you have Mach II version 1.1.1 installed in the following directory:

C:\inetpub\MachII_1_1_1

Now, in order to configure a mapping for Mach II so that all web site and web applications use Mach II version 1.1.1, you'd edit the applicationHost.config file and add the following entry (note there will be other sections within system.webServer in addition to the bluedragon section):

<system.webServer>
    <bluedragon>
        <cfmappings>
            <mapping name="/MachII" directory="C:\inetpub\MachII_1_1_1" />
        </cfmappings>
    </bluedragon>
    .
    .
    .
</system.webServer>

Then, let's say you want to configure a new web site or web application that uses the new Mach II version 1.5, but leave all the other web sites using version 1.1.1. How do you do that? It's simple: create a web.config file and place it in the root directory of your web site or web application. Within the web.config file add the following entry, which overrides the global entry in applicationHost.config (in this case, the bluedragon section is the only one we need to add to system.webServer):

<system.webServer>
    <bluedragon>
        <cfmappings>
            <mapping name="/MachII" directory="C:\inetpub\MachII_1_5" />
        </cfmappings>
    </bluedragon>
</system.webServer>

Now your new web site will use Mach II version 1.5, while all other web sites and web applications will continue to use version 1.1.1. (This example assumes the system administrator has delegated the ability to override the cfmappings configuration setting; a discussion of delegation is beyond the scope of this blog entry, but you can find more information here).

The key point is that it's possible for BlueDragon/CFML developers to configure settings for their own web site or web application by editing their own web.config without having to ask the system administrator to do it for them, and without affecting any other web sites or web applications.

This simple example only gives a tiny glimpse of the new possibilities created by the new IIS 7.0 configuration system; for more detailed information visit the IIS web site. Also, I'm going to discuss this in more detail during my keynote at CFUNITED-07, so be sure to come if you want to learn more.

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.

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.

Here's another review of the New Atlanta keynote at CFUNITED-06, written by Aaron West.

I've posted my presentation slides from New Atlanta's keynote at CFUNITED-06. You can view the speaker notes after launching the PowerPoint slide show if you right-click and then select "Screen-->Speaker Notes" from the pop-up menu (I didn't read the speaker notes verbatim--in some cases what I actually said was shortened considerably due to time constraints--but they capture the gist of what I had to say). Here are the speaker notes from slide 11, which is entitled "Key Messages" and pretty much summarizes the theme of the keynote.

BlueDragon is a mature, proven product. Since we first introduced BlueDragon in 2002—over four years ago—it has been deployed by hundreds of companies and organizations; at all levels of government—by local, state, and federal agencies—by state and federal courts; by local school districts and major universities; by churches and other charitable organizations; by banks and other major financial institutions and insurance companies; by small- and medium-sized companies, and also by the largest Fortune 500 and Fortune 100 corporations.

BlueDragon offers unique benefits as an alternative platform for deploying your CFML applications. There are reasons why these companies and organizations are choosing BlueDragon. It’s is not simply a copy or clone of ColdFusion—BlueDragon does things that ColdFusion doesn’t do and offers benefits that ColdFusion doesn’t offer. I’m not going to tell you that BlueDragon is always a better choice than ColdFusion or that everyone who’s using ColdFusion should switch to BlueDragon. But for some people BlueDragon is better and you might be one of those people. Which leads me to my third point…

You, as a CFML developer, need to know more about BlueDragon. You need to know about the different product editions: the standalone Server, the J2EE edition, the BEA WebLogic edition, and BlueDragon.NET. You need to know what it can do and what it can’t do; how it’s the same and how it’s different from ColdFusion. You need to know these things so you can make an informed decision about whether BlueDragon is the right product for you… or whether it’s not. You may take a look at BlueDragon and decide not to use it—and that’s OK—if your decision is based on knowledge of BlueDragon’s strengths and weaknesses. But if you’re not using BlueDragon because you don’t know anything about it, because you’ve never downloaded it or tried it, or never read any of the documentation; or maybe because you read something on a blog or mailing list written by somebody who doesn’t really know much about BlueDragon or maybe has old information, then you might not be using the best product for deploying your CFML applications.