ColdFusion Components - An Introduction

One of the greatest and probably most anticipated features to come with Macromedia’s Coldfusion MX is ColdFusion Components (CFCs). In its most basic form, a CFC is a collection of code and data that’s stored in a central file. In the past, you’ve probably created a file that contained all your functions, and which you could simply include in a document to have all the functions available to you. This is a very simple application of CFCs, but, as we’ll see, it’s not the whole story.

CFCs represent an attempt by Macromedia to bring ColdFusion closer to an Object Oriented Programming (OOP) language. ColdFusion is in no way an OOP language, but thanks in part to CFCs, it does boast some of the attributes that make OOP languages so popular. For instance, ColdFusion gives developers the ability to extend a piece of code to include items from another piece of code; it also gives us the ability to transplant and reuse code across a variety of systems and applications.

So how do CFCs bring ColdFusion closer to OOP, and what’s the rest of the story?

CFCs are not your normal function inclusion pages. When you create a CFC, you gain access to many more features than you would if you created an include page that contained a bunch of functions. What exactly are these features and benefits? They include:

• Security - you have the ability restrict access to your CFCs, and the methods within them, based on user roles and settings in your CF setup.
• Speed – CFCs are compiled so they execute faster. Keep this in mind when building your sites, as the first time a CFC is called, it is compiled and the output is returned; you might want to run through your site before releasing it to the public. Also remember that each time you make and upload a change to your code, the CFC will have to be recompiled -- but there’s no need to worry, as the server handles all this for you.
• Extensibility – CFCs can be expanded upon and they can share methods with other CFCs, much like Java and PHP classes. CFCs can also be called externally using the SOAP protocol or URL calls, which allows you to make them available to other programmers and other languages.
• Reusability – If you code your CFC properly and are mindful of the implications of extensibility, your CFC can be shared and moved from server to server and script to script.
• Local Reusability – Once a CFC method is invoked on a page, it’s typically reusable throughout that page. There are some exceptions to this rule of thumb, but the potential for code reuse means you don’t have to call the function multiple times on the same page.
• Documentation – CFCs can generate their very own documentation using the hint attributes in the cfcomponent and cffunction tags. To see this functionality at work, simply open up a CFC, for example http://www.example.com/myCFC.cfc, in a Web browser (note that you will have to login with either a RDS or Administrator login to see the page). The server will generate a page that documents myCFC.
• Forward Thinking – CFCs are represent the future for ColdFusion; it’s my opinion that we should embrace them now and push them to the limit so that the nice folks over at Macromedia will continue to improve upon them.

In the old days before ColdFusion MX, you might have created custom tags or User Defined Functions (UDFs), or found some other way to develop reusable code. CFCs allow you to achieve this aim, while delivering the added benefits listed here.

Terminology

Before we jump into a simple CFC, we need to understand some of the key terminology.

First, a CFC is called a Component, or a ColdFusion Component, and you can think of it as a container. Now, an empty container has no value until you fill it. We fill the component with methods, which are defined by the <cffunction> tag.

Once we have a component and fill it with methods, we can then invoke specific methods, which can be found in the component, using the <cfinvoke> tag.