A Review of CFCs

ColdFusion Components (CFCs) are considered by Macromedia to be one of the most important features in ColdFusion. They enable programmers to create true structured programs (eliminating many of the shortfalls of the custom tag architecture), to allow grouping of related functionality in CFCs and packages, and to enable object-oriented programming with inheritance. CFCs are the building blocks of ColdFusion-based Web services.

In the Macromedia ColdFusion MX 7 Web Application Construction Kit, there is a good introduction to ColdFusion Components, their features, and many of the considerations of creating them. In this chapter, we'll discuss many of the more-advanced uses of CFCs, but first we'll review some basic terminology and see what it takes to build and use CFCs in ColdFusion.

Two Types of CFCs

CFCs are of two types: components that provide groups of functions, and "instance-based" CFCs that include their own data and support object-oriented types of programming.

CFCs of Grouped Functions

The first type of CFC is just a collection of related functions (related in the programmer's mind, anyway.) You might write a CFC of this type that performs several types of statistical calculations on arrays of data, and call it ArrayStatistics.cfc. Another CFC might be just a group of all the common functions used through an application, called CommonFunctions.cfc. And yet another might contain specific functions that allow you to add and remove users from your system, UserFunctions.cfc. Each of these contains functionality grouped in a way that is logical to the author of the CFCthe first by common functionality, the next by use within parts of an application, and the last by business logic. This type of CFC is not really object oriented; it's more similar to an "import library" in C. You only need one copy of these because the functionality is independent of the data and runs on any data passed in.

Instance-Based CFCs

The CFCs that contain instance data are truly object oriented, and require a new way of thinking about functionality that is more similar to Java and other object-oriented languages. In this type of CFC, the component "is" its data, and its functions are things that it does with its internal data. An example of this might be a CFC that "is" an actor. An actor might have his (or her) own dataphone number, name, address, agent, resume, and so forth, and might also have functions that work on this data, such as answering questions and performing functionality: What's your first movie? How many degrees are you separated from Kevin Bacon? When you create this type of CFC, you want to look at a single copy of it; the answers to those questions will be different for each actor. When you create an independent copy of a CFC with data, these are called the instances. In object-oriented terms, those functions for each actor are called methods. (So the actor.cfc has actor methodsget it?)

Some Terminology

Since ColdFusion Components are object based, they use much of the same terminology as other object paradigms. But since there are significant differences between CFCs and other object oriented languages, it's important to understand the terms as they apply to CFCs specifically.

Component

Component refers, surprisingly enough, to the component itself. The names of ColdFusion Components are based on their filename, much like a Java class file. The CFC name is the name of the file without its .cfc extension (a component saved in a file called employee.cfc would be called the employee component). The location where the component file is stored on the server, in what directory and subdirectory, and what other components are stored in the same directory, therefore, all become very important in organizing a ColdFusion application that uses CFCs. Multiple components in the same directory become part of a component package.

NOTE

ColdFusion Components must use the .cfc extension as opposed to the traditional .cfm. Other than that, they are just normal CFMLtext files consisting of tags and functions. The four special tags that make a component a component will be covered later in this chapter.

Package

A package is a group of components in the same directory (and its subdirectories) on the ColdFusion server. In the later section "Managing Components," we will see how packages are used to organize components in applications, how they help prevent naming conflicts, and how they allow you to control importing and use of methods from other components.

In most cases, components are referenced with their full package name (the exception is when the component is in the same directory from which it is being used). The full package name is the path from the Web root (or custom tag root) down to and including the component name with dot syntax instead of normal file-system slashes. For example, the full package name of a component saved as Webroot\myApp\components\actor.cfc is myApp.components.actor.

Method

A method is simply what we call a function when it is contained in a component. Methods may be called (or invoked) by other methods, other components, CFML pages, web services clients, or Macromedia Flash applications.

You may hear the term method used in the same context as function. They mean the exact same thing. A reference to the "getEmployee function" may be followed immediately by instructions on how to "invoke the getEmployee method." Both references are correct and either one is fine with me. Interestingly, while it seems that method is the more common term, the actual tag used to define them is <cffunction>there is no such thing as a cfmethod tag. Yet, invocation of a function with the new <cfinvoke> tag (which you will see later in this chapter) uses an attribute called method="…" to refer to it.

Invoke/Invocation

To use a function of a component is called invoking it. As you will see later in this chapter, there are many different ways to invoke a component method: with the <cfinvoke> tag, as a Web service, from Macromedia Flash, from a URL or form post, or using object syntax.

Argument

An argument is just data that's passed into a function. Arguments in components can define their types.

Instance/Instantiate

An instance, then, is a specific occurrence of a component. You create each new instance by instantiating it. For example, for our actor CFC, an instance of that component would be used for a specific actor. For example, I could instantiate an actor component to work with an actor named Phyllis. Then, all of the component's data refers just to Phyllis (her name, resume, telephone number, and so on), and its methods affect only her record (updating or deleting, for examplesorry, Phyllis).

Property

A property is data that's contained in a component, and "belongs" only to that component. In that last example, Phyllis's name, resume, and so on would be referred to as properties of Phyllis.

Introspection

ColdFusion Components have the ability to look at themselves and produce an explanation of their features and functions. This ability is called introspection. The explanation can be produced in a number of formatsa nicely formatted HTML document ideal for teams of developers to use to see how a component works, or a WSDL document that is needed for Web Services clients to consume a component's functions, for example. It also allows CFCs to provide information about their uses to Dreamweaver in order to facilitate that tool's excellent integration feature (this feature is covered in depth in the Macromedia ColdFusion MX 7 Web Application Construction Kit). Lastly, introspection information is accessible programmatically if you want to use it for any other purpose. Later in this chapter we will cover introspection in depth.