Introducing ColdFusion Components

As you have learned in this chapter, you can use custom tags to package whatever type of processing you wish. In the last chapter, you learned how to package custom processing with the simpler user-defined functions framework.

An important part of ColdFusion is its ColdFusion Components framework. Think of the CFC framework as a special way to combine key concepts from custom tags and user-defined functions into objects. These objects might represent concepts (such as individual films or actors), or they might represent processes (such as searching, creating special files, or validating credit card numbers).

About ColdFusion Components

You can think of CFCs as a structured, formalized variation on custom tags. Whereas custom tags are very free in form and don't necessarily imply any kind of "correct" way to go about your work as a developer, the CFC framework gently forces developers to work in a more systematic way. If you choose to use the CFC framework for parts of your application, you will find yourself thinking about those aspects in a slightly more theoretical, abstract manner. And this has lots of benefits.

Because CFCs are more structured, the code is generally very easy to follow and troubleshoot. Think of the CFC framework as a way to write smart code, guiding you as a developer to adopt sensible practices.

But the most dramatic benefit is that the structured nature of CFCs makes it possible for ColdFusion to look into your CFC code and find the important elements, such as what functions you have included in the CFC and what each function's arguments are. This knowledge allows ColdFusion to act as a kind of interpreter between your CFC and other types of applications, such as Dreamweaver, Flash, and Web Services. If you want them to, these components become part of a larger world of interconnected clients and servers, rather than only being a part of your ColdFusion code.

CFCs Can be Called in Many Different Ways

This chapter and the last have been all about making it easier to reuse the code that you and other developers write. CFCs take the notion of code reuse to a whole new level, by making it ridiculously easy to reuse your code not only within ColdFusion, but in other types of applications as well.

All of the following can share and use CFCs:

• ColdFusion Pages. Once you have written the code for a CFC, you can call its methods from your normal ColdFusion pages, much as you can call the user-defined functions and custom tags you write. In this sense, you can think of CFCs as a third way of extending the CFML language.

• Flash. Client-side applications written with Flash can easily access ColdFusion Components. The Flash 6 player contains scriptable support for communicating with a ColdFusion server and interacting with your CFCs. In other words, CFCs become the logical gateway between your ColdFusion code and the Flash player. The integration between CFCs and Flash is tight. It is almost as easy to use CFCs within Flash code as it is within another ColdFusion page. In Chapter 26, "Integrating with Macromedia Flash," you will see how easy it is to use the CFCs developed in this chapter within the Flash client.

• Web Browsers. If you wish, you can allow Web browsers to visit and interact with your CFCs directly, without your even needing to create a separate ColdFusion page that uses the CFC. Of course, you can control whether this is allowed, whether the user first needs to log in, and so on.

• Other Applications That Support Web Services. You can turn any ColdFusion Component into a Web Service by adding just one or two additional attributes to your CFC code. It will then be available as a resource that can be used over the Internet by any other application that supports Web Services, like other Web application servers, the various pieces of the .NET and J2EE platforms, and other languages such as Perl.

In other words, if you like the idea of reusing code, you'll love the CFC framework even more than the UDF and custom tag frameworks.

CFCs are Object-Oriented Tools

Depending on your background, you may be familiar with object-oriented programming (OOP). Whether you know OOP or not, CFCs give you the most important real-world benefits of object-oriented programming without getting too complicatedexactly what you would expect from ColdFusion.

NOTE

Don't let the OOP term scare youthis isn't your father's object orientation. The introduction of CFCs hasn't turned ColdFusion or CFML into a complex, full-blown object-oriented language. CFCs aren't obsessive-compulsive. Whether your father may be is a different story.

Without getting too deeply into the specifics, you can think of object-oriented programming as a general programming philosophy. The philosophy basically says that most of the concepts in an application represent objects in the real world, and should be treated as such. Some objects, like films or merchandise for sale, might be physical. Others, like expense records or individual merchandise orders, might be more conceptual but still easy to imagine as objectsor objectified, like many of Orange Whip Studios' better-looking actors.

ColdFusion's CFC framework is based on these object-oriented ideas:

• Classes. In traditional object-oriented programming, the notion of a class is extremely important. For our purposes, just think of an object class as a type of object. For instance, Orange Whip Studios has made many films during its proud history. If you think of each individual film as an object, then it follows that you can consider the general notion of a film (as opposed to a particular film) as a class. Hence, each individual film object belongs to the same class, perhaps called Film. In ColdFusion you don't actually ever create a class; CFCs are your classes.

• Methods. In the object-oriented world, each type of object (that is, each class) will have a few methods. Methods are functions that have been conceptually attached to a class. A method represents something you can do to an object. For instance, think about a car as an object. You can start it, put it into gear, stop it, and so on. So, for a corresponding object class called car, it might have methods named Car.startEngine(), Car.changeGear(), Car.avoidPedestrian(), and so on.

• Instances. If there is a class of object called Film, then you also need a word to refer to each individual film the studio makes. In the OOP world, this is described as an instance. Each individual film is an instance of the class called Film. Each instance of an object usually has some information associated with it, called its instance data. For instance, Film A has its own title and stars. Film B and Film C have different titles and different stars.

• Properties. Most real-world objects have properties that make them unique, or at least distinguish them from other objects of the same type. For instance, a real-world car has properties such as its color, make, model, engine size, number of doors, license plate and vehicle identification number, and so on. At any given moment, it might have other properties such as whether it is currently running, who is currently driving it, and how much gas is in the tank. If you're talking about films, the properties might be the film's title, the director, how many screens it is currently shown on, or whether it is going to be released straight to video. Properties are generally stored as instance data.

CFCs and Method Inheritance

In addition to the OOP concepts just listed, ColdFusion's CFC framework also supports the notion of inheritance, where different object classes can be derived from a parent object class. There might be other types of objects that are related to the Film class, but have additional, more specific characteristics (perhaps ComedyFilm, which would track additional information about how funny it is, and ActionFilm, which would track how many explosions occur per minute).

NOTE

Once you start talking about this concept, you usually need to start using other object-oriented vocabulary words, such as subclassing, overriding, overloading, descendants, polymorphism, and so on. If none of those words means anything to you, don't worry. The CFC framework implements the concept in a straightforward way that sidesteps many of the thornier points of traditional OOP implementations. This isn't your father's inheritance.

You can learn all about CFC inheritance in this books companion volume, Advanced Macromedia ColdFusion MX 7 Application Development. See also the extends attribute of the <cfcomponent> tag in Appendix B.

The Two Types of Components

Most CFCs fall into two broad categories: static components and instance-based components.

Static Components

I'll use the term static to refer to any component where it doesn't make sense to create individual instances of the component. Often you can think of such components as services that are constantly listening for and answering requests. For instance, if you were creating a film-searching component that made it easy to search the current list of films, you probably wouldn't need to create multiple copies of the film-searching component.

Static components are kind of like Santa Claus, the Wizard of Oz, or your fatheronly one of each exists. You just go to that one and make your request.

Instance-Based Components

Other components represent ideas where it is very important to create individual instances of a component. For instance, consider a CFC called ShoppingCart, which represents a user's shopping cart on your site. Many different shopping carts exist in the world at any given time (one for each user). Therefore, you need to create a fresh instance of the ShoppingCart CFC for each new Web visitor, or perhaps each new Web session. You would expect most of the CFC's methods to return different results for each instance, depending on the contents of each user's cart.