Distribution

There are three versions listed on Adobe Labs: Macintosh, Windows 32 bit and Windows 64 bit.  Currently there are no Linux versions available, and from comments on the forums, there is no plan to release a Linux version at launch.  This is very irksome, since about 20-30% of the developers I know use Linux as their primary development platform, especially with the news about CF9′s full support of Ubuntu.  Mark Mandel has managed to put together a tutorial on how to install ColdFusion Builder on Linux, so really it looks like Adobe just isn’t willing to hire someone to maintain and Q.A. a linux release.

Installation

Installation comes in two forks, similar to the Flex Builder.  There is a stand-alone version, which installs a new Eclipse 3.4.2 instance, along with the ColdFusion Builder plugin.  The standalone also appears to contain some bits and peieces of Aptana, such as the HTML, CSS, and JavaScript editors, as well as Aptana’s FTP support.   There is also a “plugin version” which only works with 3.4.2, not version 3.5, or 3.4.1.  This means that realistically, you probably aren’t going to be able to use the plugin version if you’ve got an existing Eclipse install, unless your install is almost bleeding edge, but not quite.

First Impressions

As we’ve come to expect from Adobe, the visual experience booting up and running CFBuilder is very good.  Visually, the application looks very nice.  RDS support is basically required to use ColdFusion builder, so anyone who isn’t doing local development will prettymuch have to beg, borrow or steal an RDS password for a shared development server.  Based on the server admins I’ve worked with, if you or your group don’t maintain your own ColdFusion development server, you’re best off switching to Local Development.  It’s just the only way.

The Snippet support is almost identical to what many of us CFEclipse users have come to expect over the years, right down to the $${variable} substituion.  Unfortunately, while the snippets are stored in an XML format, it doesn’t appear to be the same schema as the CFEclipse snippets.  It’s likely a simple .xsl transform could turn all of your existing CFEclipse snippets into ColdFusion Bulder snippets though.

One very nice feature of the ColdFusion development perspective is the “TailView” component, which allows you to watch your log files for new entries.   This is a capability that Linux and Unix users have been very familiar with for years, but which is astoundingly hard to find on the Windows platform.  Integrating it into the IDE is a very nice touch, and allows you to use <cftrace> for debugging very easily.

Speaking of debugging, the stepwise debugger plugin from ColdFusion 8 is included in the install.  I haven’t used the debugger in ColdFusion 8 extensively, but it appears to be integrated seamlessly with the CFML editor view, so that you can set break points.  I’m not sure whether thats an improvement over the CF8 debugger, but it’s certainly very nice.  One caveat, you must make sure that Line Debugging is enabled in your ColdFusion Administrator.  Of course it requires RDS, but it’s definitely worthwhile.  Additionally, the ability to watch expressions and see variable values is really nice, and the handling of CFCs, structures and arrays works very well.  I’m most impressed with the debugging features.

The “Outline” view in ColdFusion Builder is another feature that CFEclipse users will be familiar with.  Unfortunately, the ColdFusion builder team didn’t choose to include the (in my mind) more useful “Object View” which shows which methods and parameters are available in CFCs.

The code assist does a moderately good job of finding variable names to offer up as code completion when typing.  Unfortunately, it only appears to interrogate the current file looking for variables.  It would be nice if (like the Eclipse PHP Development Environment) it searched the library and execution paths to find which classes and variables were defined, and give you code assist for all variables and methods.  However, given the highly dynamic nature of ColdFusion and CFCs, it’s understandable that this is a huge challenge, and hasn’t been implemented.  It would be a clear advantage though, if the team were to implement it.

The “extensions” are kind of nice, but I don’t see them having a large impact on my day to day coding.  They seem to be a great way to stand up a new application in a short time, allowing you to build large ammounts of code quickly, but for the more common “Brown Field” work that makes up 80-90% of my work days, its probably not going to be of much use.

Summary

The Good – Debugging is amazing.  Really good job here. I know some folks will really like the Word Wrapping, which has been a notable hole in the Eclipse platform for a very long time.  The Aptana integration makes editing JavaScript and CSS along with your ColdFusion code very nice and easy to do.  Youv’e got a good start with the code assistance, and I’m looking forward to what will happen in future versions.  Hopefully there will be some even better things to come.

Low Hanging Fruit – The ability to import a CFEclipse Snippet library or connect to a SnipEx server would be nice.  Implementing the CFEclipse “Methods” style view should be pretty easy, and it’s much more useful than the outline view when working with CFCs.

A bit of a pain – Basically requiring RDS support is a thorn in the side of lots of developers in corporate environments.  Corporate server admins read the CF documents that say that “RDS is a security hole in a production server” and think that means that they shouldn’t let developers have access to it.  It’s a long, hard battle that nobody really wants to fight.  Some bits, like the “Service Browser” offer up entirely unhelpful messages such as “Unable to get meta data for cfc.” without any explaination of what could be done to fix it.  Likewise, I got “Unable to fetch server mappings. Reason :null” in my console on startup… What does that mean?  Nobody seems to know.  Fortunately, most of these errors are in places that don’t affect the core usability of the system, but hopefully they’ll be cleaned up a bit before the final release.

The Bad – The lack of Linux support is really a deal breaker for me.  I do about 50% of my development on Windows, and 50% on Linux.  If I have to choose between using ColdFusion Builder 1/2 the time, and CFEclipse 1/2 the time, or just using CFEclipse full time, I’ll probably go with the CFEclipse option.  The lack of support for Eclipse 3.5 puts this solidly behind the curve when it comes to Eclipse plugins.  This is more of a problem with the Eclipse platform, since each yearly release changes so much that every plugin has to be completely rewritten in many cases, but it would be nice if Adobe were to release a plugin that actually works with the newest stable Eclipse version, instead of constantly trailing one release.  Further, because of its narrow focused Eclipse version, even running ColdFusion Builder and Flash Builder in the same eclipse instance may be a challenge.  A little more version compatibility would be nice.

When originally installing the Flex Builder 3 plugin for eclipse, I used the default path (i.e. C:\Program Files\Adobe\Flex Builder 3 Plugin\).  When I tried to re-run the installer, It reported that I already had a Flex Builder Plugin instance at that location, and would I please choose another directory.  Not wanting to clutter my hard drive with extra copies of the Flex Builder plugin, I decided to poke around and see what I could do to use the existing Flex Builder Plugin in my new Galileo installation.

What I eventually happened on was a very nice, clean way to install a single instance of an Eclipse plugin, and allow multiple copies of Eclipse use it.   It’s pretty straight forward, and assumes you’ve already got a copy of Eclipse installed, and a licensed copy of the Flex Builder 3 Plugin installed.

First off, navigate into your eclipse directory.  Mine is C:\Program Files\Eclipse\Galileo\ .  This should be the folder which contains your eclipse.exe file.  Under this directory, if there isn’t already a directory named “links”, create one. Navigate into the links directory.  Create a new text file named “com.adobe.flexbuilder.feature.core.link”.  Edit the file, and add the following contents to it:

path=C:/Program Files/Adobe/Flex Builder 3 Plug-in

Close the file, and start Eclipse.  Now go into your Window Menu, select “Open Perspective”, and “Other”, and you should see your Flex Development Perspective listed.  It’s even smart enough to pick up the license key from your previous installation, so you don’t have to dig out the old key to reinstall. However, for some reason, when I did this it lost my installed Flex SDKs.  To fix this, I went to the “Window->Preferences” dialog, and navigated to the “Flex->Installed SDKs” option.  I removed the two entries for “Flex 0.0″ which were listed, and re-added the two existing Flex SDKs: c:\program files\adobe\flex builder 3 plug-in\sdks\3.2.0 and c:\program files\adobe\flex builder 3 plug-in\sdks\2.0.1   You must mark one of these as default by clicking the checkmark next to it on the screen.  After this, click Ok, and you should be good to go.

If you’re doing ColdFusion development, don’t forget to also install the ColdFusion extensions for Eclipse at C:\program files\Adobe\Flex Builder 3 Plug-in\Installers\ColdFusion Extensions for Flex Builder, and JSEclipse is also pretty helpful at C:\program files\Adobe\Flex Builder 3 Plug-in\Installers\JSEclipse

However, the recent TIOBE Rankings for April 2008 show that not only is ColdFusion not dead, but it’s actually on the rise once again. While it still ranks below the likes of Ruby, Python, and C#, ColdFusion has surpassed Lua, ActionScript, and Groovy.

Of course, there are plenty who will argue the validity of using the TIOBE index, since it’s based on Search Engine results, rather than actual market positions, or sales figures, but at very least, ColdFusion is doing a good job of generating posts about ColdFusion programming all over the internet.

My pattern is reliant on two things:

1. The CFC must have (or inherit) a public init function, which performs the duties of a traditional object “Constructor”.
2. The init function must return a reference to the object, generally by ending with

In the traditional paradigm, invoking an object is (almost) always performed in two steps. First , you get a fresh new object with either the CFOBJECT tag, or the CreateObject function. This object’s psuedo-constructor (any code outside the CFFunction tags) has been executed, but any intializing values (dsn for a DAO, the MachII.framework.AppManager for a MachII plugin, etc..) have not yet been fed into the object, so it’s really “half baked”. It’s not ready for general consumption. In order to make it ready for general consumption, you have to call an initializer on it. By convention, this function is called “init”, and accepts any arguments that are necessary to make the object “ready for primetime”.

A few people began to notice that this pattern broke your code up into multiple lines, which could be accidentally separated, resulting in the unitialized object references being released into the wilds of your program. One of these people came up with the bright idea of returning a reference to “this” from the init function. This allows your init function to be chained to the CreateObject call like so:

<cfset newObject = createObject(“component”,”foo”).init() />

This still is possible to mess up, but as Joel Spolsky once pointed out, one of the keys to making your code stable is making wrong code look wrong. If all of your CreateObject statements are immediately chained to an init function, then it’s easy to track down errors where your instantiated-but-unitialized objects are released into the wild. If you see a CreateObject anywhere that isn’t immediately followed an init, then you know at least one thing you need to fix.

This development inspired me. I knew that CFINVOKE could be used to in one operation, instantiate an object, and call a function on that object. The return value of that function call could be saved. What would happen if I ran a CFINVOKE on an init function that returned a reference to “this”? It turns out that the result is exactly the same as the CreateObject chaining that people were recommending before, but it didn’t require access to the “forbidden” functionality.

I’ve run across a trend in ColdFusion code that’s out there living in the wild web, to terminate “empty” tags with a />, like in XML. The best explaination I’ve heard for this behavior is to make ColdFusion code “well formed” XML. But what I don’t see, is how this explaination holds water.

Maybe an XML programmer out there can point out, how is this:

<cfset var foo=ListFirst(bar,”,”) & listGetAt(bar,4,”,”)>

any more proper syntax than:

<cfset var foo=ListFirst(bar,”,”) & listGetAt(bar,4,”,”) />

</minor rant>