ColdFusion Plays Well With Others

Continuing on with the series I started on Tuesday, I’m going to explore ColdFusion’s ability to play with many other technologies, and do so very well.

First, let’s start with what ColdFusion was designed for, getting information out of databases. ColdFusion ships with drivers for talking seamlessly to the following database systems:

• Apache Derby    
• MS Access    
• MS SQL Server    
• MySQL     
• PostgreSQL     
• DB2
• Informix Dynamic Server    
• Oracle
• Sybase

Does that mean if you are a FoxPro or SQLite developer, you’re out of luck? Hardly – if it has a JDBC driver you can talk to it with ColdFusion.

Databases are only a portion of what you have to deal with, especially if you are talking to back end systems with various interfaces. The can include directory servers, file servers, mail servers, etc. Here’s a non exhaustive list of ColdFusion tags that can talk to those sorts of servers:

 

That’s a pretty big list. Keep in mind that it’s not just about talking to those services; it’s about easily talking to those services. Yesterday, I showed the cfexchange tags and cfmail tags in action. They’re all pretty much that easy and concise to use.

Next, ColdFusion can call just about anything that can be run from the command line via cfexcecute:

#results#

That’s not necessarily compelling. Pretty much every programming tool can make calls to the shell. But I think it’s important to point it out, keeping in mind that this is a must have feature for any tool.

But shelling out to the OS, running a command, reading it into a variable and parsing it is a pain. It’s a lot of extra coding, extra bug trapping, and usually a performance hit. So it would be nice if you could interface with certain other tools without having to do that.

I kinda, gave a sneak preview of some of this content the other day, when I showed getting information from .Net into Java in two lines of code:

I didn’t have to import any libraries to accomplish this, it just worked from the moment I installed ColdFusion. I consumed a .Net assembly, got a string from it, and passed it a Java Object. That was just a string, but if the return had been a more complex object, ColdFusion would have converted it to a native ColdFusion structure. Any errors would have been caught and delivered via ColdFusion’s error handling mechanism. The same applies to the Java call.

The .Net communication was added in ColdFusion 8, but the Java communication has been around since ColdFusion MX 6. The reason behind this is the often overlooked fact that ColdFusion is written in Java, runs on Java, and can be looked at as Java framework. Anything Java can do, you can get done in a ColdFusion page or component. You might have to drop down to coding in Java to do it, but that’s pretty easy to do:

#result#


As you can see, I can use the result generated by Java without any special conversion.

Finally, ColdFusion can run with support from Adobe on many platforms:

• Windows
  • Windows XP
  • Windows Vista
  • Windows 2000
  • Windows 2003
  • Windows 2008
• Mac
  • OS X 10.4, 10.5
• Linux
  • Red Hat 3.0, 4.0, 5.0
  • SUSE 9, 10
• Solaris
  • Solaris 9, 10
• AIX
  • AIX 5L, 5.2, 5.3

Those are just the supported platforms. It’s also quite possible to run CF on Ubuntu or Centos. (But I must stress, Adobe doesn’t support these distros of Linux, yet.)

I hope, I was able to show you in this long, but frankly shallow overview, that ColdFusion can talk to a lot of different system, using many different interfaces, and do so on pretty much every mainstream platform you could need.