Planning your application

The heart of the FuseBox methodology is to organize ColdFusion applications, written in unstructured CFML, in an object oriented way. That is, the organization of the application code and the flow of the user through the application will be organized around the main objects that the application is intended to deal with.

You may find that this is not much different from how you end up organizing your applications anyway. But the FuseBox methodology forces you to identify and describe objects at an early stage, aiding you in your planning process.

	Step	Example
1	Describe what the application will do in general terms. You can probably do this in one sentence.	This application will allow managers in our department to organize information about the departmental projects they manage.
2	Refine your description. Use several sentences to be more specific about what kinds of actions will be performed.	Managers will be able to see existing projects, view information about them, and create new projects. Projects will consist of tasks, which can be crated, viewed, and edited. Tasks will be assigned to staff members, so it will need to be possible to add or remove staff.
3	Make a list of the major things -- objects -- that the application will have to manipulate.	Projects Tasks Staff
4	Make a list of the actions that will be performed on each thing. Some of the most common actions that appear over and over again in web applications are: list, create, edit, and delete.	Projects List projects Create a new project Edit a project Delete a project Add tasks to a project Remove tasks from a project Tasks List tasks Create a new task Edit a task Delete a task Assign a task to a staff member Change or remove an assignment Staff List staff Add a new staff member Edit a staff member Delete a staff member

Most web applications have a database back end, and in most cases the objects you identify in step 3 will correspond to tables in your database. You database will probably also contain additional tables, such as lookup tables or tables defining many-to-many relationships. But if your database does not contain a table for an object you identify in step 3, you may want to take another look at the relational design of your database. If you don't have a database design yet, you can typically work from the list of objects in step 3 to start one.

Unlike objects, the actions (or FuseActions) you identify in step 4 generally don't correspond to parts of your database. Instead, they correspond to chunks of code that perform each action in your application. In fact, most actions correspond to a web page that users will use to perform that action.

Sometimes it is hard to know whether to consider something as an object or not. In these situations it is helpful to take a hard look at the scope of the application. Even though something could be an object in the abstract, for purposes of the application it may be just a property of another object. Another way to decide whether something is an object is to see if you can specify a significant number of actions for it in step 4.

The next step in this site, coding your application, discusses how to turn the outline in step 4 into an application framework.