|MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA|
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:
The actual directory structure could be:
If 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:
When you instantiate a component that's stored in a package, you refer to it using dot notation:
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 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.
This differs from variables you set in the "local" scope of a method by using the