Development Methodologies

Development methodology in relation to ColdFusion application design refers to the existence of a defined set of conventions or procedures to guide you through a development project. A development methodology might define your application's physical file structure and might dictate what type of template goes into what folder. It might define naming conventions for your code templates and how those templates interact with each other.

There are many popular development methodologies floating around the ColdFusion development community. Any one of them might meet your needs and help you to design more scalable and easier-to-maintain applications. Understanding the approach of these development methodologies might even help you to define your own practice.

It is not our intention here to explain all intricacies of any development methodology. We want to help you understand the use and importance of utilizing a development methodology in your projects.

Fusebox

One of the most popular, widely known, and widely accepted development methodologies is Fusebox. Fusebox has successfully been adapted to serve as an application-development methodology for Active Server Pages (ASP), PHP, and Java Server Pages (JSP) applications. This discussion focuses on Fusebox 3, which is the latest specification. Although some of the fundamental concepts are the same, Fusebox 3 bears little resemblance to Fusebox 2. Fusebox 3 is built around the following key features:

A nested model that supports communication between circuits. Circuits now can have a parent/child relationship, leveraging the power of inheritance. This is a departure from Fusebox 2, where circuits were independent of each other.
A nested layout model
Fusedocs, which provide a Program Definition Language and documentation in an eXtensible Markup Language (XML) format
A defined set of key or core files
Exit fuseactions (XFAs)
A public application program interface (API)

Core Files

Fusebox 3 introduces different core files, each prefixed with FBX_:

FBX_Fusebox_CFxx.cfm. The xx is dependent on the version of ColdFusion supported. Your Fusebox application has a separate file for each version of ColdFusion supported. The FBX_Fusebox_CFxx.cfm file replaces many of the custom tags from Fusebox 2 and should be called by the default file of your application's home circuit.
FBX_Settings.cfm. This is an option file that is used to set variables. The job of the FBX_Settings.cfm file is to set up the environment in which the application runs. This replaces app_Globals.cfm, and variables specific to a circuit application are set in the app_Locals.cfm files used in Fusebox 2.
FBX_Circuits.cfm. This is required in the home circuit and provides mappings of circuit aliases to physical directory paths. The circuit aliases are not required to be the same as the directory names.
FBX_Switch.cfm. This is a CFSWITCH statement that contains a CFCASE for every fuseaction that the circuit handles.
FBX_Layouts.cfm. This is an optional file, used to set the variable Fusebox.layoutDir, which points to the directory where layout files are kept. It also sets Fusebox.layoutFiles, which points to the layout file to be used.

Fusedocs

Unlike Fusebox 2, which used a proprietary format developed by Hal Helms, Fusebox 3 uses XML to document what a fuse does and the required input/output. The fusedoc has three elements. Responsibilities is the first and it is required. The other two elements are properties and io. Responsibilities provide an explanation of what the fuse will do. Properties contain a number of subelements that provide information, such as history, related to the fuse. The last element, io, defines the input and output of the fuse. A more detailed explanation of these elements and their attributes can be found in the Fusebox 3 documentation.

Fusebox Basics

Fusebox helps developers build robust and scalable web applications easily, surely, and quickly and it's surprisingly simple. A Fusebox application works by responding to requests to do something a fuseaction, in Fusebox parlance. This request might come about as a result of a user action (a user submitting a form, for example, or clicking a link), or it might occur as a result of a system request.

When you submit the form, index.cfm is called. In fact, everything an application can do is done by sending a fuseaction request to index.cfm. This file, so central to the methodology, is called the fusebox. When a fusebox is called, a variable called fuseaction is also sent.

The fusebox's main job is to route a fuseaction request to one or more code files called fuses. These files are typically small and have well-defined roles.

The routing begins with a CFSWITCH statement, located in the FBX_Switch.cfm, that examines the value of the fuseaction. After it finds a matching value in one of the CFCASE statements, the code between those particular CFCASE tags is executed. In the Fusebox methodology, the CFCASE code is used to set up an environment in which one or more fuses can be called to perform whatever actions are needed to do the work requested by the variable fuseaction.

A fuse can be used to display a form, check whether a user's password and username match those found in a database, and show a menu of user options. In short, anything a web application can do can be done through the use of fuses.

Well-written fuses are very short and restrict themselves to doing only one or two things. They are easier to write (and maintain), are less buggy, and are easier to debug. They also facilitate code reuse. You seldom need a catchall type of fuse, but you often will need fuses that handle a specific task.

Fuses have one or more exit points, which are areas where the action returns to the fusebox. Every link on a user menu is an exit point, just as each drill-down action to get more information is an exit point. Some exit points are visible and require user interaction, such as submitting a form or clicking a link. Other exit points are not visible. An example of an invisible exit point is a call to a CFLOCATION tag within a user-authentication template. Whether generated by user interaction or by the application itself, exit points in fuses always return to the fusebox with a fuseaction.

This is a great place to discuss the feature of XFAs. XFAs are the exit points of a fuse. In Fusebox 2, fuseactions were hard-coded into exit points:

 <form action="index.cfm?fuseaction=verifyUser">

However, this impairs code reusability. If you want to reuse a fuse whether in another application or in a different point in the same one you now must deal with the fact that your exit fuseactions might not be the same. They might vary according to the context in which they are used. This means that you must begin introducing conditional statements in your code. Now, each time you want to reuse the fuse, you must open up the file, alter the existing code, and then save it. This introduces the very real possibility that you will introduce a bug into the code. Further, it reduces readability (and maintainability) of the code, making it just plain ugly.

Fusebox 3 enables you to use XFAs to replace the hard-coded references. This lets you create fuses that can be used anywhere, without worrying about where a form should be submitted or a link should be pointed.

 <form action="index.cfm?fuseaction=#XFA.submitForm">

The value of the fuseaction is set in the FXB_Switch.cfm file:

 <cfswitch expression="#Fusebox.fuseaction#">          <cfcase value="verifyUser">                  <cfset XFA.submitForm="verifyUser">                  <cfinclude template="qry_verifyLogin">          </cfcase>          <cfcase ...  </cfswitch>

Fusebox Conventions

It's helpful to categorize fuses into different types. For example, some fuses display information, forms, and so on to users; others work behind the scenes to do things such as process credit cards; and still others are responsible for querying databases. Many Fusebox developers find it helpful to use a prefix when naming a fuse. Such a prefix conveys the fuse type. Examples of these are shown in Table 3.4.

Table 3.4. Fusebox 3 Prefixes
Fuse Name with Prefix	Explanation
`dsp_ShowProductInfo.cfm`	A display type fuse used to show or request information from a user
`act_SaveUserInfo.cfm`	An action type fuse used to perform an action without displaying information to a user
`qry_GetUserInfo.cfm`	A query type fuse used to interact with data-sources without displaying information to a user
`url_ProcessOrder.cfm`	An action type fuse used to redirect an action

These naming conventions are best thought of as suggestions. You can use the naming conventions outlined here or not, depending on what suits you best.

If you do use them, will you use an underscore to separate the prefix from the fusename, or will you use the mixed-case spelling that many developers prefer? Personally, I like the mixed-case usage, but you might prefer something else. Whatever you choose, don't get bogged down in disputes over naming conventions; Fusebox is primarily about developing successful applications, not about naming schemes.

Encapsulation

You have seen how fuseactions are returned to the fusebox, and you have had a glimpse of the mechanism the fusebox uses to call helper fuses (a CFSWITCH statement). Fuses really do all the work in a Fusebox application. The fusebox itself acts like a manager, delegating work to one or more of these fuses.

One of the principles of modern programming is encapsulation, which states that, as much as is possible and reasonable, applications should be divided into areas of related functionality. We do this constantly in many aspects of our lives.

One of the great things about Fusebox is the flexibility it gives you as the developer. This not only lets you decide on things such as naming conventions, but also it enables Fusebox developers to experiment with new ideas without fear of running afoul of any Fusebox police. This, in turn, lets Fusebox evolve, whether to stay abreast of technology developments or simply to incorporate good ideas that weren't originally envisioned. Different developers have different goals and bring with them different techniques. Such creative diversity can only be good for the methodology.

One idea that has proven very successful in the object-oriented world is that of inheritance, a mechanism for reusing code (and surely the Holy Grail of many programmers). Having written a perfectly good circuit application, such as a user module, for one application, we surely want to use it in others and to do so without having to make wholesale changes to the code.

The original Fusebox specification doesn't make this particularly easy, so you had to muck about, changing app_Locals.cfm and app_Globals.cfm. The idea of inheritance made this process both easier and safer. Many developers welcomed the idea of nesting in Fusebox 3, which was a departure from the Fusebox 2 concept of treating each fuse or circuit as independent. Although Fusebox 3 supports a concept of inheritance that enables child circuits to be inherited from their parent circuit, circuits should have the same properties or functionalities associated with inheritance in object-oriented languages.

Summarizing Fusebox

Although we could spend all day delving deeper into the Fusebox methodology, let's wrap this discussion up by recapping what we've just discussed.

Fusebox is an application-development methodology that enables developers to create highly reusable and scalable applications by providing a framework for the application. This framework employs the use of a template that is central to the application that serves as a fusebox. It routes requests, calls includes, and sets variables.

Fusebox enables applications to be clustered or nested off the main fusebox to ensure that your application can be easily extended and enhanced. Fusebox enables developers to write code that is reusable and easy to maintain.

To learn more about Fusebox 3, visit www.fusebox.org/. This site contains the latest Fusebox specification and a number of excellent articles, presentations, and tutorials on Fusebox.

cfObjects

cfObjects is another popular development methodology available to ColdFusion developers. cfObjects purports to be a simple and efficient framework for building applications that can take advantage of object-oriented programming principles, including inheritance, polymorphism, and encapsulation.

Object-oriented programming enables us to better model the problem domains within our systems and designs. With an OOP methodology and framework, we can tackle very complex applications using an approach that is natural because it is similar to the way a human solves daily problems.

By combining the power and flexibility of ColdFusion with an object-oriented methodology, ColdFusion developers gain the capability to develop, share, and extend reusable class hierarchies that solve the common problems that occur in web-application design.

By making use of ColdFusion features such as exception handling, verity collections, and the request scope, you can implement OOP constructs and class libraries.

cfObjects is a collection of highly specialized custom tags, Visual Tag Markup Language (VTML) files, and Studio Wizards. At the core of the framework are different custom tags:

CREATEOBJECT
INVOKEMETHOD
DECLAREMETHOD
COLLECTGARBAGE
CACHECLASS
DUMPALL

These custom tags enable developers to create object-oriented class libraries or object collections. The value or the framework is in the depth of the class libraries, not the framework components. cfObjects was designed to enable any company, organization, or individual to create specialized class libraries that plug into the framework. That is, cfObjects is not a class library it is a framework for implementing and using class libraries.

Classes

Classes are implemented as a collection of ColdFusion templates residing under a class subdirectory (one per class). The class subdirectory must exist under a directory named by a ColdFusion mapping. Within each class subdirectory, there must exist a special file named class.cfm. This file defines the class and superclass name. Class.cfm is loaded by CREATEOBJECT.

Methods

Methods are implemented as specialized custom tags that exist within the class subdirectory. Each method should contain a call to DeclareMethod as the first line within the CFML file.

When a method is invoked, the cfObjects framework makes all passed attributes available to the method, including the special attribute named "self," which is a reference to the object instance. This is useful for accessing the instance variables of the object.

You can download the framework for cfObjects along with all the custom tags. Remember, however, that cfObjects is not a product. It provides a framework and a development methodology for ColdFusion developers to follow. You can learn more about cfObjects at www.cfobjects.com.

SmartObjects

SmartObjects is a freely available, open-source framework that enables developers to convert a directory of CFML templates into a customizable, reusable, object-oriented component, or class. This is done by placing a class definition file, called public.cfm, in the directory. This template uses the CF_CLASS custom tag to define the directory as a class, and it makes it available to be used by other applications.

After it is defined, SmartObjects classes are not accessed directly through a web browser, but are called by and embedded in other templates. This is called creating an instance of, or instantiating, the class using the CF_OBJECT custom tag. Each instance of the class is called an object, and it is represented by a structure variable type.

Every CFML file in the class directory is called a method, and it represents any executable function such as add, edit, delete, or find. The calling application uses the CF_CALL custom tag to execute any of the methods that the object supports.

Classes can inherit methods from other classes, which means that they do not have to define all their own functions by themselves. Base classes provide functions that subclasses can override or extend. Using inheritance, you can simplify your applications by maximizing the amount of reusable code that you can access. You can add new methods to a class, or you can replace existing methods with new functionality. You can learn more about SmartObjects at www.smart-objects.com.

Other Established Methodologies

There's no one methodology that we can recommend that you use. We do think, however, that understanding several development methodologies helps you to better understand the application-development process. I'm sure no one has thought of every possible complication that can arise in application development. Let's take a look at a few more development methodologies.

Switch_box

Switch_box is a methodology that has definitely been influenced by other popular development methodologies. The use of the word "box" in "Switch_box" is really more coincidental to "box" in "BlackBox" or "Fusebox" than a variation on these techniques. In fact, some of the conventions of the Fusebox methodology are used in Switch_box.

The idea of classification and organization of information is as old as the human mind. It is how we understand ideas and hold on to them. It is intrinsic to our human nature. Thus, the idea for boxes and nesting of boxes is a really great way for our minds to understand the problem paradigm.

Switch_box introduced the notion of a message vector as means for directing program execution from a uniform resource locator (URL). It builds on the traditional dotted-object syntax with two important distinctions. First, it is designed to be a Hypertext Transfer Protocol (HTTP) attribute. Second, it is intended to show the clear separation of a method name from the object name.

The word "vector" means direction, and directions are calculated from coordinates. In the case of Switch_box, the axes for coordinates are the object list and the method list.

In traditional object-oriented syntax, sometimes discerning the method from the object can be a guessing game and requires beforehand-knowledge of objects and their methods. In Switch_box, the objective was to make the separation clear and unambiguous. This is the reason for putting the colon between the object tree and method tree. In Switch_box, the rule for a message vector is that any message without a colon is a method for the current box; otherwise, all message vectors must be properly formed with the object tree and method tree. In addition, in the method axis, Switch_box enables the use of a compound method tree. This feature is necessary for handling predicate noun actions and makes the process of writing program code more efficient.

Along with a message vector, the notion of a "switch operator" has also been introduced. The switch operator is merely a means to calculate the message vector path. The standard object-oriented example Books.Catalog.Adults.Inventory.Display would be in the message vector format of Books.Catalog.Adults.Inventory:Display would read as "Books switch Catalog switch Adults switch Inventory switch Display." The CF_SWITCHBOX custom tag handles the message-vector switch operators. To find out more about this methodology, check out Switch_box online at www.switch-box.org.

BlackBox

The BlackBox style of developing ColdFusion applications is based on the premise that developers like to have control over their pages. Its strengths enable developers to access the brains of an application without worrying about the predefined presentation tier.

BlackBox enables the same functionality to be used in several sections of the application, but in very different ways. It is designed so that employing this functionality creates the illusion of functions. It enables developers to easily nest applications and to create attractive URLs. BlackBox also enables developers to easily integrate multiple applications within the same web site.

BlackBox is a very simple methodology. It employs a few custom tags and functions to access individual templates and to access integrated applications. You can find out more about the BlackBox methodology by visiting www.black-box.org.

Developing a Personal Methodology

In the last several pages, we've looked at several development methodologies. Some of them are popular, well-publicized, and quite successful; others continue to struggle to gain acceptance in the ColdFusion development community.

I'm not going to stand up and tell you to use one or the other. I'm not going to try to point out the strongest attributes of one or the cracks in others. What I will tell you is that having a development methodology is important and that creating an established set of development guidelines helps you to maintain a minimum level of standardization in your application code.

Here are a few things to consider when you start to develop your own ideas about development methodology:

Coding standards. Every application needs to have some coding standards in place. Coding standards include everything from tag case to the proper scoping of variables. Presentation-tier code calls for the combination of HTML and CFML. The presentation of your HTML and CFML code should be standardized so that it is easy for one developer to read another developer's code or to extend the application for any given point.
Code commenting. I know that this could be wrapped up in a bit of information regarding coding standards. However, I'm isolating this topic because of its importance. Too many times I've seen developers write code that makes total sense to them but to anyone else, it's like reading Klingon.

Commenting should be part of your standard template. A usage comment should be included at the top of the template to provide information on the purpose of the template, its creation date, and its author. At the bottom of the template, I like to include a revision log so that developers understand the iterations that the template and the embedded presentation or functionality have gone through and the reasons that the code was added or removed.
Naming conventions. The names that you give to files, links, and processes are as important as the accuracy and organization of the code that you write. It is important to employ a naming convention in your application that is easy to understand. The naming convention should help to avoid confusion in relating the process call, the template name, or the link to their functions or purposes within the application.
Application framework. Of course, ColdFusion developers can take advantage of the application framework provided by the Application.cfm and OnRequestEnd.cfm templates. Remember to use these templates properly and not to call query code or employ presentation elements within these templates. They are best used for the evaluation and creation of global variables and application-level variable.
Business logic calls. Business logic calls can usually be divided into functions and actions. Think of functions as specific tasks that the application processes perform. You can use a business logic template to handle the variable values that are created in a multistep process in a particular application transaction.
Data interface transactions. The handling of data interface transaction should have some type of organized approach. By data interface transactions, we are referring to the templates that invoke the calls to stored procedures or that make query calls. By defining each template by its purpose and function within the application, developers can easily find and update code. This area also gives a perfect location to employ commit and rollback strategies and query caching strategies.
Variable standardization. Web-based applications handle variables by passing them from template to template along the URL string or by passing them from form template to action template. The standardization of variable scopes is one of the issues that arises in any application and that gets more and more difficult to manage as your application gets more complex.

There are several custom tags out there that can help with this issue. They simplify variable testing and evaluation by converting all variables to the same scope. You can convert them to a local scope, but I suggest the request scope to avoid any conflicts with variables of the same name that are created within the template that calls the standardization implementation.
Exception and error handling. ColdFusion give us the power to use its built-in, error-handling features. We have the capability to use tags, such as CFERROR, CFTRY, CFCATCH, CFTHROW, and CFRETHROW. These are error-handling methods that we can employ within our code. We can also take advantage of ColdFusion's site-wide error handling. These types of errors are things that happen while the template is being processed by ColdFusion. They are pretty predictable and enable us to define custom error-handling templates for a more user-friendly, error-message display.

Exceptions might occur within our application at runtime. Validation and client-side scripting should take care of most of these, if not all. On the off chance that you've left out some validation or some validation does not work properly, you should have a catch-all in place to handle situations where the user supplies invalid values to the application.

Well, hopefully this gives you a good starting point and a heads-up on the things you need to consider when planning your application-development methodology. As we mentioned earlier, it helps to study the existing and established methodologies so that you can glean their strengths from them and adapt them to your needs. You also should make sure to learn from the mistakes that other developers have made in the past. Many of the existing methodologies have been refined as a result of those mistakes and are much more thorough today.

Summary

Understanding your application requirements is crucial to the planning of the infrastructure on which your application runs and to the development of an architectural plan for your application. The definition of a development methodology for your project is also important. We've seen how a methodology can simplify the interaction between logical chunks of code and can make the reuse of code easier to implement . We've also discussed a few established methodologies and some that are on the brink. Whether you choose one of these methodologies or come up with one of your own making, remember these tips:

A methodology should serve as a framework for the development of your application.
Your methodology should be well-defined.
Your methodology should be well-documented.
Your methodology should be adhered to throughout your application.
Your methodology should be understood and employed by all developers on your project.