The Five Types of Fusebox Variables

Fusebox Lifecycle Process Article

The Five Types of Fusebox Variables

I recently came to a revelation that there are only five types of variables in a Fusebox application. It has taken me a long to recognize this. Now that I have this understanding, writing Fusedocs is suddenly much simpler and more accurate. To save you all the experimentation time that I went through, I'd like to share with you what these five types of variables are.

To understand these variables, let's first look at a fuse. A fuse is a single file in an application. When architected properly, the beauty of a fuse is that it is independent of the entire application. A fusecoder writing the logic for this fuse doesn't need to understand everything about the application when given a Fusedoc. The Fusedoc itself doesn't need to explain the entire application. Instead, what the Fusedoc needs to define are the variables the fuse needs and the variables the fuse produces. This is documented in the <io> section of the Fusedoc.

Without the <in> variables in the Fusedoc, certain fuses cannot run. Those fuses don't care where the <in> variables were created, it just cares that the <in> variables exist. On the flip side (no pun intended), without the <out> variables in the Fusedoc, another fuse in the application may not run. This connection is how fuses work together without knowing what the other fuses in the application actually do.

A single fuseaction in a Fusebox application may run many fuses. It may run application specific fuses like FBX prefixed files or it may run user defined fuses to do things like queries, actions and displays. Regardless of how many fuses are run, they are run in a specific order. Each one may create a variable used in another fuse in that one fuseaction.

Fuseactions connect together through links, forms and server-side redirects. When a user clicks a link, he may pass a URL variable from that link to another fuseaction in the application. Or when the user fills out a form, he may pass a series of variables to another fuseaction. Or the user might call a fuseaction that in turn calls another fuseaction via <cflocation> or <cfmodule>.

Back to the five types:

XFAs
Form/URL Out Variables
Form/URL In Variables
Internal In Variables
Internal Out Variables

Let's take them one at a time.

XFAs

The first type are "eXit FuseActions" (XFAs). An XFA is a link or form submission on your web page. When a user clicks a specific link or form button they are taken to another fuseaction. This is how web pages in your Fusebox application are connected together. An example of an XFA is the "I'm Feeling Lucky" button on the www.google.com home page. When the user clicks that button, they are taken to another page on the google.com website. In Fusebox, this button is an XFA.

Form/URL <out> Variables

When a web page has a link or form on it, it passes variables from one web page to another. In Fusebox, form and URL variables are converted to a single scope so these variables can be combined together. An example of a form or URL <out> variable is the www.google.com search form on the home page. This page has a single input box for typing in your search string. This search string is a form/URL <out> variable. These variables come in many shapes and sizes - sometimes they are input boxes or radio buttons, other times they are hidden variables that the user does not see.

Form/URL <in> Variables

When a variable is passed out of a form or link from one web page, it is passed into another web page. Again, because Fusebox converts form and URL variables to a single "attributes" scope, we can combine these together into form or URL <in> variables. For a fuseaction to run, it may require certain form or URL variables defined by the user from a previous web page. An example of this is the google.com search results page. The search string you typed into the search form is now used on the search results page to search for your topic.

Internal <in> Variables

When a page has multiple fuses on it, variables are passed between fuses. Sometimes the variable comes from a fuse in the switch, other times it comes from an FBX fuse. For a fuse to run, it may require that certain variables are defined from another fuse in the fuseaction. An example of this is the google.com search results page. This page might contain two fuses: a query fuse and a display fuse. The display (dsp_) fuse displays the recordset of websites. The recordset is an internal <in> variable. Without this recordset, the display fuse cannot display the search results.

Internal <out> Variables

When a fuse requires a variable that is not passed in from another web page, another fuse in the fuseaction needs to define that variable. This is an internal <out> variable. An example of this is the same google.com search results page described above. This page would contain two fuses: a query fuse and a display fuse. The query (qry_) fuse obtains the data from the database and produces a recordset (as an <out> variable) available for the display fuse to display the results. So the query fuse makes an internal <out> variable and the display fuse uses an internal <in> variable.

That's Interesting, But Now What?

Understanding the distiction between these variables should make writing Fusedocs much simpler. The next time you begin to write your Fusedocs from your prototype, try to look for these five types of variables. Begin by identifying each XFA on each prototype page. Next, identify the form/URL <out> variables with each XFA. Next, match up the form/URL <in> variables from the form/URL <out> variables. Finally, identify internal <in> variables and match up internal <out> variables with the internal <in> variables.

This is the process I use when I convert my prototypes over to Fusedocs. I find it incredibly effective. Going through this process helps to ensure that I identify every variable passed around in my Fusebox application. Let me know if it works for you! I have a Prototype to Fusedoc converter tool that is designed around this concept, if you have some time, check it out!

The Fusebox conference is coming up soon and I highly recommend you attend. I am personally trying something new this year. This year I will have a demonstration table instead of speaking. I'm hoping it will give me a chance to talk with you all one on one and show you some of the powerful Fusebox tools I've created.

Click here to read about the Fusebox conference

Steve Nelson