Top Ten Tips for Developing ColdFusion Components
Pages: 1, 2, 3
8. Get Organized
Where you store your CFCs can have an impact on how efficiently and effectively you write your applications. Although it's possible to just save your CFCs in the same directory as the .cfm pages that call them, you would be missing out on a big benefit to using CFCs: code reuse. By storing all of your CFCs in a central location, it's possible for multiple applications (or multiple parts of an application) to share them. One of the easiest ways to do this is to save your CFCs in packages. In the Java world, packages are used to organize class files into related groups. In ColdFusion MX, packages work in the same basic way. Packages map directly to a directory structure on your server. They follow a customary naming convention that reverses your domain name.
So, if your company's domain is "example.com," you would create a package hierarchy for your CFCs that looks something like this:
com.exampleThe actual directory structure could be:
c:\webroot\com\exampleIf you don't want your CFCs accessible to web browsers, move the hierarchy out of your web root, and create a mapping to the com directory in the ColdFusion Administrator. This way, you can still refer to your CFC hierarchy within your code as if it were located in your web root, without having to potentially expose your CFCs to curious browsers.
Within the package hierarchy, you can group your CFC by application or functionality:
com.example.storefront
com.example.storefront.ui
com.example.blog
com.example.utilWhen you instantiate a component that's stored in a package, you refer to it using dot notation:
<cfset session.myCart =
createObject("component", "com.example.storefront.shoppingcart")>In this case, you are instantiating shoppingcart.cfc, located in the com.example.storefront package. Note that you don't specify the .cfc extension on the component you are calling.
9. Be Careful Not to Overexpose Your Data
When working with variables inside of your CFCs, make sure you aren't exposing your data any more than you intend to. Depending on how you scope (or don't scope) your variables, you may make a variable readable/writable to another CFC method, or even code outside of your CFC. Here's a list of the three main scopes you need to concern yourself with when writing CFCs, along with an explanation of where they can be accessed.
Variables/Unnamed Scope
Variables in the variables scope are available only within the CFC. They are available to the constructor code, and to all component methods and any pages they include. They may be prefixed with the variables prefix or left unscoped (often called the unnamed scope). Variables in the variables scope that are set within the calling page are not automatically available within the component's variables scope. Additionally, variables in the variables scope exist as long as the component object exists. This allows them to persist between method calls.
Local Scope
This differs from variables you set in the "local" scope of a method by using the var keyword. These variables are available only to the method in which they are defined and any pages included by that method. Additionally, local variables do not last beyond the life of the method call. The local variable
scope differs from other variable scopes in that there is no scope prefix used for the variable. Note that
if you do not define the variable with the var keyword, the variable exists in the variables scope, not the local scope.
this Scope
The this scope is functionally equivalent to the this scope in JavaScript and ActionScript. Variables in the this scope are available to all methods within a CFC, any pages they include, and the page that calls the CFC. Within a CFC, you refer to variables in the this scope using the this prefix: this.varName. Outside of the CFC, you use the component name to reference variables in the this scope: myComponent.varName. Note that this applies only when you instantiate the CFC as an object via the cfobject tag or the createObject() function; not when a component method is invoked using the cfinvoke tag, without instantiating the CFC separately.
10. Be Resourceful
Although CFCs are still relatively new, there are a lot of good resources for learning more about them. Your first stop should be the ColdFusion MX 6.1 LiveDocs. After that, you may want to check out these additional resources:
CFCZone.org: Clearinghouse for all things CFC. Contains open source CFCs, a blog, CFC FAQ, and a listserv dedicated to CFC discussion.
Mach-II: A development framework built using CFCs, which has the potential to do for ColdFusion developers what Struts has done for Java developers.
Macromedia ColdFusion MX Developer Center: Macromedia's official ColdFusion developer center, with several articles and tutorials related to CFCs.
Corfield.org: Contains a blog, as well as other information on various CFC-related topics, from Macromedia's Director of Architecture.
cfoop: A site dedicated to object-oriented programming in ColdFusion MX.
Fullasagoog: A blog aggregator that contains more than 25 ColdFusion MX blogs, many with regular CFC-related postings.
Rob Brooks-Bilson is a freelance writer and a senior technology manager at Amkor Technology. He is the author of O'Reilly's Programming ColdFusion MX, 2nd Edition (covering CF MX 6.1).
O'Reilly & Associates recently released (August 2003) Programming ColdFusion, 2nd Edition.
Chapter 11: "Advanced Database Techniques," is available free online.
You can also look at the Table of Contents, the Index, and the full description of the book.
For more information, or to order the book, click here.
Return to the Web DevCenter.
