For many web developers, whenever JavaScript is mentioned it provokes a rye smile; JavaScript is one of those programming languages that is rather avoided than embraced. This is not the fault of the language itself, but rather the browsers. A few years ago, the landscape of client-side scripting was a bleak scene. Browser inconsistencies, particularly with the dominant Internet Explorer, implementation bugs and numerous target platforms made developing client-side JavaScript a tricky undertaking.

To the consternation of these same developers, the landscape changed and Web 2.0 hit the mainstream. Almost overnight, every website on the internet wanted to use or was using AJAX. Marketers joined the bandwaggon and every feature requested had to involve something dynamic and revolutionary. Thus JavaScript development quickly hit the forefront of peoples minds and became as important as any server-side technology available at the time.

Over the next few blog posts, I will be using the popular frameworks jQuery, Yahoo! User Interface Library (YUI), ExtJS and Adobe’s Spry with ColdFusion to demonstrate various techniques, such as autocomplete and form validation.

Today ColdFusion moved into the next stage of its life and became a teenager, hopefully not a precocious one!

Happy 13^th Birthday ColdFusion.

Adobe ColdFusion has had a long and illustrious life. The first version of ColdFusion–written almost entirely by one person, JJ Allaire and then called “Cold Fusion”–was released in 1995. This first version, although revolutionising how web applications were built, was primitive by modern standards, doing little more than database access.

Although originally built in Visual C++, Allaire, around 1999, took the decision to rewrite the entire ColdFusion engine in Java–a project named “Neo”–which would allow for greater portability among different platforms. The rewrite, released under the monicker MX 6, would prove to be somewhat problematic and a wholescale update to the version resulted.

In 2001 Allaire was acquired by Macromedia. This union brought with it the integration of Macromedia’s Flash platform via Flash Remoting; a huge step towards rich Internet applications.

In 2005 it was the turn of Macromedia to be acquired and they merged with Adobe. A period of instability in the ColdFusion world resulted, brought about by the knowledge that Adobe was a company that developed tools, not programming languages. However, following a successful release of ColdFusion 8 in 2007 and the announcement that a version 9 would be developed, code-named “Centaur”, fears about ColdFusion’s future have subsided–albeit the continued debate over “ColdFusion is Dead” remains boiling in the background.

The primary distinguishing feature of ColdFusion is its associated scripting language, ColdFusion Markup Language (CFML), which compares favourably to its rivals, JSP, ASP.NET, or PHP and resembles HTML in syntax. “ColdFusion” is often used synonymously with “CFML”, but it should be noted that there are additional CFML application servers besides ColdFusion, and that ColdFusion supports programming languages other than CFML, such as server-side Actionscript and embedded scripts that can be written in a JavaScript-like language, known as CFScript. Adobe ColdFusion also includes native support for Flex, PDF, Verity and the embedded Derby database amongst a host of other features.

ColdFusion 9 is set to be an exciting release, much like its predecessor, with more features added to the core tag set, whilst also integrating other technologies such AIR and Hibernate.

Exciting times lay ahead. Let’s hope Adobe takes full advantage with such a fine product.

See Also:

• ColdFusion Wikipedia entry
• ColdFusion Markup Language Wikipedia entry
• Railo - Free, Open Source alternative CFML Engine
• SmithProject - Free, Open Source alternative CFML Engine
• BlueDragon - Free, Open Source alternative CFML Engine

In the past, the US has held a near monopoly not only in ColdFusion-based user groups, but also conferences, with CFUnited, cf.Objective() and the more general Adobe MAX leading the way.

But the landscape is changing and the UK is challenging for its share of the scene. 2008 is seeing a renaissance in the ColdFusion world following on from the buzz created around the release of ColdFusion 8 in 2007 and the eagerly anticipated future release of ColdFusion, codenamed Centaur. This buzz has resulted in not one but three conferences for 2008: CFUnited Europe was held in London in March, Scotch-on-the-Rocks was held in Edinburgh in June and soon we will see the return of CFDevCon.

The inaugural CFDevCon one-day-conference was held back in 2006, in Croydon, but in September 2008 it is heading down to what is arguably one of the creative capitals in the south of England, Brighton. The conference has not only become a two-day conference, but its scope has moved beyond simply Adobe-based products, with the introduction of Microsoft-based technologies, specifically IIS7.0, Silverlight and SQL Server 2008 and technology-agnostic topics such as Regular Expressions, Search Engine Optimisation (SEO) and Accessibility.

As with all great conferences, CFDevCon has a great line-up of speakers with the likes of Sean Corfield, Hal Helms, Peter Elst, Peter Bell, Aral Balkan and Simon Bailey, to name a few, all presenting sessions.

So, lets get excited people, support the conferences and user groups and evangelise ColdFusion.

Following a conversation with a friend regarding how ColdFusion handles arrays and structures in ‘the background’, I was interested to find out what Java classes each were mapped to. This was a relatively simple case of using the functions getClass(), getSuperClass() and getName() to parse out the name of the Java classes.

<!--- Arrays (repeat up the hierarchy) --->
<cfdump var="#arrayNew(1).getClass().getName()#">
<cfdump var="#arrayNew(1).getClass().getSuperClass().getName()#">
<!--- Structures (repeat up the hierarchy) --->
<cfdump var="#structNew().getClass().getName()#">
<cfdump var="#structNew().getClass().getSuperClass().getName()#">

What became immediately apparent was that both were handled differently. In the case of a ColdFusion array, the parent class was the java.util.Vector, which seemed obvious. The Vector class implements a growable array of objects. Like an array, it contains components that can be accessed using an integer index. However, the size of a Vector can grow or shrink as needed to accommodate adding and removing items after the Vector has been created.

ColdFusion structures, however, are handled entirely differently, with the parent class being a coldfusion.runtime class. In fact, as we can see below, the code to handle a ColdFusion structure is entirely written for ColdFusion until the root class of java.lang.Object. Clearly ColdFusion does some complex wizardry to handle the complex nature of structues (associative arrays).

The class hierarchy for an Adobe ColdFusion array:

java.lang.Object
	java.util.AbstractCollection
		java.util.AbstractList
			java.util.Vector
				coldfusion.runtime.Array

The class hierarchy for an Adobe ColdFusion structure:

java.lang.Object
	coldfusion.util.CaseInsensitiveMap
		coldfusion.util.FastHashtable
			coldfusion.runtime.Struct

Being an inquisitive person, I applied the same code to Railo and BlueDragon, with equally interesting results.

The Java class hierarchy behind a Railo array:

java.lang.Object
	railo.runtime.type.ArrayImpl

The Java class hierarchy behind a Railo structure:

java.lang.Object
	railo.runtime.type.StructImpl

The Java class hierarchy behind a BlueDragon array:

java.lang.Object
	com.naryx.tagfusion.cfm.engine.cfData
		com.naryx.tagfusion.cfm.engine.cfJavaObjectData
			com.naryx.tagfusion.cfm.engine.cfArrayData
				com.naryx.tagfusion.cfm.engine.cfArrayListData

The Java class hierarchy behind a BlueDragon structure:

java.lang.Object
	com.naryx.tagfusion.cfm.engine.cfData
		com.naryx.tagfusion.cfm.engine.cfJavaObjectData
			com.naryx.tagfusion.cfm.engine.cfStructData

Adendum: Ben Nadel has a good little post on ColdFusion Data Types from Different Sources and How ColdFusion Sees Them.

CFML is the name of the scripting language used by ColdFusion and several alternative server environments. It stands for ColdFusion Markup Language and is similar to HTML in appearance in that it uses tags. CFML is the code that powers ColdFusion, a program available from Adobe (formerly Macromedia), as well as such engines as BlueDragon, IgniteFusion, Railo, Coral Web Builder, DigitalLattice Orange and other web development platforms.

ColdFusion originated as proprietary technology based on Web technology industry standards. However, it is becoming a less closed technology through the availability of competing products. In fact, one could now make the argument that ColdFusion is even less platform bound than say raw J2EE or .NET, simply because ColdFusion will run on top of a .NET app server (New Atlanta), or on top of any J2EE app server (Websphere, JRun, Tomcat, etc.) In theory, you could move a ColdFusion app unchanged from a J2EE app server to a .NET app server.

Currently, alternative server platforms generally support Coldfusion MX 6.1 functionality, with minor changes or feature enhancements.

I have listed some of the alternatives in order of maturity/populrity. However, I will leave it up to you to decide which one is the best and easiest to implement. Please tell me your experiences.

BlueDragon

The BlueDragon Server family of Java-based servers (Server and Server JX) enables the stand-alone deployment of CFML. Both BlueDragon Server versions contain a built-in web server for development and testing, and each integrates with Microsoft IIS, Sun ONE/Netscape/iPlanet (JX only), and Apache web servers for deployment.

BlueDragon offers flexibility for the deployment of ColdFusion Markup Language (CFML) pages with native technology platform integration on the operating system, web server and database of your choice.

Visit the New Atlanta website at http://www.newatlanta.com to download the latest version of BlueDragon.

Railo

Railo is a ColdFusion Compiler for translating and executing of ColdFusion based websites. The Compiler translates the ColdFusion code into Java classes which can be executed on a Java server. Railo also comes with a runtime engine, which contains all necessary libraries for the translated code. Railo automatically detects wether to translate a ColdFusion file or when to use the runtime engine. You can compare Railo at best with JSP interfaces. JSP uses an other syntax but the main functionality is almost the same. Because Railo implements most of the JSP interfaces, it is highly compatible to JSP interfaces.

Visit the Railo website at http://www.railo.ch

IgniteFusion

IgniteFusion is a ColdFusion compatible script engine that runs ColdFusion scripts. In addition to Coldfusion CFML compatibility IgniteFusion has functionality that extends Coldfusion. Although in Beta, it is approaching release.

Visit the IgniteFusion website at http://www.ignitefusion.com to download the scripting engine.