Basic Fusebox Concepts
Fusebox borrows many of its essential concepts from other systems. First, Fusebox is a way to organize program code. Second, Fusebox is a way to manage growing applications by organizing the application directories in a hierarchy. Third, and perhaps most fundamentally, Fusebox is a way to think about applications and the art of building them. Comparisons have been drawn between the Fusebox controller file and computer networks. Now let's discuss each of these essential concepts in more detail.
A Way to Arrange Code
A great deal of thought has gone into the idea of organizing applications into some kind of logical framework. Code organization schemes are as old as computers. Back when computers used punch cards, programmers kept routines in tidy order. If you got a card out of sequence, your program did not function properly. And heaven forbid you drop a box of cards on the way to the computer! More discussions of code organization choices appear in Chapter 14, "Construction and Coding," such as the popular Model-View-Controller (MVC) framework.
The easiest concept to observe about Fusebox is the impact it has on your application's codewhere you store files and how you arrange your directories. The Fusebox specification defines how to arrange your program's code into easy-to-manage chunks. What is the big deal with organized code?
Although many people quickly recognize the value of using a standard approach to arrange code, some of the benefits are often overlooked.
ColdFusion has been an incredibly successful language primarily due to its low entry threshold. That is, ColdFusion does not require a great deal of study and knowledge of programming to get started.
Because so many people who have had no formal background in programming or application development get involved in developing ColdFusion applications, a great deal of ColdFusion code is disorganized or poorly written. Sure, it does the job, but unfortunately, ColdFusion's reputation has unfairly suffered as a result. Instead of recognizing that ColdFusion accommodated an amazingly wide spectrum of experience from complete novice to application guru, rumormongers proclaimed that ColdFusion could not scale well.
Scaling means that a completed application will be able to successfully handle workloads larger than those for which it was originally designed. In the case of web applications, it usually translates to a large increase in the number of page requests or simultaneous users that the system handles.
Database issues aside, when an application is poorly designed and constructed, it is generally not able to scale very well. Program logic that works well for one or two users might overstress the server when several hundred users all try to use it at once. Many ColdFusion applications are poorly designed and constructed, simply because their creators never considered the issues involved in effective application design.
However, ColdFusion's reputation as a small-scale application server is not deserved, and indeed has been greatly reduced in recent years. Projects such as RoomsToGo.com (the largest retailer of furniture online) and Autobytel.com (one of the largest car sales sites) have proven that ColdFusion can scale effectively when the application is properly conceived and executed. Both of these high-volume sites are not only ColdFusion efforts, but they also both use Fusebox as their architecture.
Still quite Fusebox, you may notice that AutoByTel.com uses ?action= rather than the familiar ?fuseaction= in the URL.
A Way to Manage Growing Applications
The responsibilities of a manager can be defined by a constant struggle to determine when a project will be completed and how much it will cost. If, as a manager, you do not have a good idea of how the application's code is organized, then the uncertainty factor rises rapidly. Fusebox project managers can use this framework again and again, regardless of the size of the project, which aids in code reuse. For example, you might have written a report for accounting last week. This week, you can literally copy and paste it into the whole intranet without changing a thing.
Using Fusebox is good for project managers, but Fusebox also mimics the way managers work. If you have ever managed a project, you know that most of your time is spent coordinating the efforts of others. Managers do not tend to produce much, but they encourage and allow those underneath them to produce more, better, faster. They are skilled at assigning tasks, which helps manage a project's size. A comparison of Fusebox and corporate managers reveals that they share some of the same methods for getting work done. Fusebox encourages code to be highly specialized and focused. The structure helps to control all the smaller pieces. The controller files excel at delegating tasks.
If you are a reader of the Dilbert comic strip, you are quite familiar with the Pointy-Haired Boss (PHB), the epitome of a manager without a clue. Dilbert is funny because we can relate to the title character; most of us have worked for a PHB at one time or another. Consequently, it might be hard to imagine corporate managers as a model for solving a problem, but there is a reason that management hierarchy rules the structure of companies today.
People can only process so much information in any given day. Using a flat organization (where managers are nonexistent and everyone is an equal), every member of the group must communicate his ideas and information to every other member of the group on a regular basis. Obviously, this is inefficient and can easily grow to the point where everyone spends all his time involved in communication, with no time left to actually get work done.
ColdFusion applications that lack a real structure act similarly. Every page can link to every other page. In fact, every page must link to every other page to get something done. If you add a page, all the other pages must be updated. Every page must be aware of every other page in the system.
This is where the manager comes in. Sacrifice one person's ability to directly produce but give that person the role of facilitating communication, and everyone else gets more done. By filtering out all the other stuff that goes around other parts of the organization, team members can focus on the skills for which they were hired in the first place.
The manager can see the "big picture" of the organizationwhat projects are currently underway, what areas of uncertainty lie ahead, and what teams need resources to complete their job. A good manager is a master delegator. If a manager goes "into the trenches" to produce and directly contribute, communication suffers and projects slow down.
PHBs notwithstanding, by organizing and regulating the flow of information between teams, managers streamline business. Fusebox's controller file duplicates the purpose of a manager by passing requests off to focused portions of the application. If an employee needs to arrange a meeting with another department to complete a project, the manager knows whom to contact and facilitates the communication. Similarly, if a web site user wants to see a list of all products on sale, the Fusebox controller knows which files accomplish that task.
A Way to Think About Applications
When you sit down to work with an application, do you have a mental concept of it in your head? What does it look like in your mind's eye? Can you fit it all into your head at once? Do you think of the application's code as being organized in a particular way, or does it all just sort of run together in a big jumble?
Part of the problem of working with unorganized code is just trying to envision the application. Without a defined model, the picture that forms tends to be abstract. It is hard to imagine what happens when a particular template runs, how information is passed from one template to another, and what a change in one template does to another template. You might tend to think in terms of web servers and page requests or maybe streams of ones and zeros flying around if you understand that kind of thing. Although there is nothing wrong with this view, there is nothing tangible about it either. You cannot visualize the application. Or, as Beethoven said:
"[The work] rises, it grows, I hear and see the image in front of me from every angle... and only the labor of writing it down remains..."
Beethoven was a musical genius who was fully capable of composing a complete symphony in his head. Most folks are not as good at programming as Beethoven was at composing; we need a structure to our applications. Thankfully, we use things every day that can give us some valuable models for our applications. One example that closely resembles Fusebox is a computer network router.
Fusebox Mimics Networks
Over time, routers have helped organize network traffic immensely. Two of the most successful early network topologies were ring and bus architectures, shown in Figure 1.1.
These two architectures had one thing in common: They were based, as are all networks, on the idea of broadcasting packets of data from one machine to another.
Figure 1.1 Ring and bus networks.
As you can see in Figure 1.1, the bus architecture (at top) worked by machines sending packets addressed to other machines onto the bus, the central line in the figure. Each machine would check the address on every packet that went by. If the packet belonged to the machine, it would make a copy of the packet and read it. Otherwise, the packet would be ignored.
Acting somewhat like a bus network in a loop, IBM's Token Ring worked by each packet attaching a token that carried the address of the recipient. When the token passed the recipient machine, the machine stripped off the packet. If the token passed a non-recipient machine, nothing happened and it continued around the ring.
As you can imagine, both of these approaches meant that a lot of packets were flying around on the wires. Then came a new topology, and the problem got worse.
The newer topology, called a star, used a central hub to send packets from one machine to another. A hub was a simple concept; it took whatever came in one port and sent copies of it out on all the other ports. This made great sense when you had a single hub at the center of several computers. Shown in Figure 1.2 is the classic star network.
Figure 1.2 Star network.
Networks based on hubs eventually reached a practical limit on the number of ports, so network engineers expanded the capacity of the hub by linking hubs together. However, that technique was not scalable. If you linked too many hubs, the multiplied traffic would cause collision problems, with traffic moving slowly.
The answer to this problem was the router. A router is the hub's smarter cousin. Whereas a hub simply copies what is received in one port to all the other ports, a router sends a packet only to the destination. Using strategically placed routers, network planners were able to create huge networks. In fact, the Internet is a series of interconnected routers.
By organizing and regulating the flow of traffic between workgroups, network routers streamlined the networking industry. Routers act as a big switch. If one computer wants to talk to another computer, the router essentially connects those two machines to each other. Similarly, Fusebox uses a master controller file to directly pipe a page request to the correct set of files. The controller file handles every action that the system can perform.
Traditional ColdFusion applications have no hub. Page requests are all point-to-point. As the system grows in size, developers can't remember which pages link where. It becomes extremely difficult to keep a clear picture of the application in your head. Imagine trying to memorize exactly what a pile of spaghetti looks like and where each noodle winds. Tough, huh? Now imagine a map of the interstate freeway system. That is a lot simpler, isn't it? It is pretty simple to find your way from Atlanta, Georgia to Atlanta, Idaho even if you have never been to either of those places. Freeways have structure, like Fusebox. Spaghetti has no structure, like traditional ColdFusion applications.
Back to Thinking About Applications
We started this discussion with the idea that applications are difficult to think about in tangible terms, and that Fusebox provides an easier concept to grasp. Each of the real-world examples (network routers and managers) is tangible if you are familiar with it. When someone mentions one of these examples, you instantly have an idea of what it is about and how it works.
Fusebox does something similar with applications. As you gain experience with Fusebox, you will become more comfortable with the associated terminology, and your applications will be easier to visualize. Now we just have to tell you what Fusebox really is.