Introduction
Writing applications within a multi person team can be difficult. Sharing applications between two teams can become even more difficult. Effectively sharing applications with 30,000 other developers such as with the ColdFusion community is almost impossible... unless everyone adheres to standards for writing these shared applications. The Fusebox Organization has been assembled to create these standards.

The Fusebox Organization consists of ColdFusion developers from around the world and at this time it does not cost anything to join. The Organization holds occasional chat sessions; anyone may participate. The chat sessions allow the ColdFusion community to have state what the Fusebox standards will be, so it is encouraged that as many Cold Fusion programmers participate in the chat sessions as possible. To be notified of the chat sessions, enter your contact information at the Fusebox web site.

The Fusebox Organization's web site, http://www.fusebox.org contains details about upcoming Fusebox standards, chat sessions, and example applications. An exciting event in which some members of the Fusebox Organization will be participating is the U.S. ColdFusion Conference on July 24-26 in Ft. Collins, Colorado, USA. More can be read about this at http://www.secretagents.com/uscfug

Problems the Fusebox Standards will solve
Before writing the Fusebox standards, we (about 50 CF developers) discussed some of the problems ColdFusion developers run into when writing ColdFusion applications. Here are two of the main problems, which the Fusebox Specs attempt to solve. We feel sure we will encounter more problems and as a community we will determine the solutions.

Problem 1: One of the main issues with writing CF applications is writing "Spaghetti code". Imagine a ball of spaghetti. Now add a strand to the ball. Now add another strand to the ball and another. This is how most applications are written. They are first designed thinking they thought of everything, then the client says 'wait I need this..." so it gets added. Pretty soon after doing this, the code for the application becomes unmanageable.
Solution 1: ColdFusion applications are file based. So the easiest place to lose track of what an application is doing are in these files. The Fusebox Specifications will attempt to solve this problem of managing files so all Fusebox based applications "look" and "work" the same (at the code level).

Problem 2: Different types of Databases
Solution 2: CF shops do not use the same databases, some use Access, others SQL Server, others Oracle. It's important that Fusebox applications be database independent. Primary keys are one of the main issues that are affected by this. So we set a standard "Integer" data type for the primary key. This "Semi-autonumber" field is incremented within the application instead of within the database. This allows for transfer among different types of databases.

Conclusions
The Fusebox standard is going to help CF developers by allowing applications to work better together. Whether applications are being integrated among different developers within your own CF shop or different developers in the CF community, the Fusebox standards will help connect these different ColdFusion applications. We encourage you to join us in our discussions about the standards. You can find out more information at: http://www.fusebox.org.

In this issue of CF Advisor, you can read up on the latest FuseBox specs.