Submitted by Tom Luttrell, firstname.lastname@example.org
After a ColdFusion programmer learns the basics of how to develop advanced web sites, the one thing he should invest time in is learning to make code modular and reusable. Why? It will save you and anyone else who uses your code many headaches. Modular and reusable code not only saves time in doing repeated work, it is easier to maintain and integrates into other projects faster.
One common criticism of ColdFusion is that it is not object-oriented, meaning it does not natively support modularity. ColdFusion already has the features necessary to make code modular, however, by using custom tags or cfmodule.
My advice is to put as much of your code into custom tags or modules as you can. There is one downside to this: Performance might be slightly degraded. Because each module or custom tag has its own memory space, nesting them too deep or using them too many times can cause a page to become heavy or expensive in memory and possibly slower as a result. If you are careful, however, the benefits of making most of your code modular will outweigh the weaknesses.
You can use any flavor of the Fusebox methodology out there, but using any method of making your code reusable is far better than using none at all. I happen to use a variation of Fusebox that ensures that most of the files being used are called as a custom tag or cfmodule.
When using custom tags, a good programmer tends to restrict calls to a few scopes: attributes and local variables. Attributes are the variables that get passed in to the module when the tag is called.
Use cfparam to default all the variables your file will need at the top of your page. Try to restrict calls to one scope during most of your code. If the file will only be called as a custom tag or module (as in some flavors of Fusebox), the only types of variables you should ever call directly within the main part of your files are attributes or local variables. When you do need to access variables in other scopes, default these variables at the top of your file using cfparam before "localizing" it. This gives you the flexibility to override this value by explicitly passing in an attribute value. The following code provides an example of this:
<CFPARAM NAME="Request.FuseBox.LogicalPath" DEFAULT="../.."> <CFPARAM name="Attributes.LogicalPath" DEFAULT="#Request.FuseBox.LogicalPath#"> <CFOUTPUTT>#Attributes.LogicalPath#</CFOUTPUT>
Values that might change should never be hard-coded. Instead, they can be set as defaults for attribute parameters so that, if the module is to be reused again and requires different values, they can be overwritten.