Logical architecture of a Fusebox application
The logical architecture of a Fusebox app resembles a hub and spoke system, with all actions returning to the hub (the Fusebox). This sort of structure is also known as a circuit application.
Figure 1 Fusebox App Structure
A circuit application is usually a single directory of files and generally does a few related tasks such as search. The overall application is called the home application, which is made up of many circuit applications. This is where Fusebox gets its name. Just like an electrical Fusebox, it is set up as a group of circuits (”fuses”) that are ready to send the user to whichever part of the application his or her next click requires. Each of these fuses has a name, called a fuseaction. Fuseactions are used to turn on the appropriate switches to cause the required action. So the Fuseaction is the key to the application?without a fuseaction, the application will only do the default fuseaction.
INDEX.CFM and the FuseactionThe home application is ALWAYS engendered in a file called INDEX.CFM, which is placed in the root directory of your application. Every link on the website will always be to this file! When creating the user interface for the application, each URL link or form will be to INDEX.CFM and then contain the name of the fuseaction that will do the work necessary if it is activated. For a URL, the fuseaction will be contained in the query string, for instance: http://localhost/INDEX.CFM?fuseaction=search. For a form, the usual method of placing the fuseaction is to call the INDEX.CFM file in the form?s action field, but then include a hidden form field with the fuseaction:
Now, The question is for internal workings of the INDEX.CFM file. It will use CFINCLUDEs to combine files together to create a working application. But how does ColdFusion use the fuseaction to know which files to combine? This is done using CFCASE/CFSWITCH. The CFCASE/CFSWITCH tags perform a similar function to a CFIF statement with a bunch of CFELSEIFs. But, using CFSWITCH/CFCASE will run much faster than a similar series of CFIF/CFELSEIF. When there are many ELSEIF’s, the logic is exactly the same. For example, here is a logical statement using CFIF/CFELSEIF:
“Wooof” “Meeooow” “Moooooo” [[Silence]] |
Using CFCASE/CFSWITCH, the same statement would be:
“Wooof” “Meeooow” “Moooooo” [[silence]] |
Since CFSWITCH/CFCASE is faster, it is the method used in the Fusebox architecture. INDEX.CFM will contain CFSWITCH/CFCASE to determine what the user wants to do. Think of the INDEX.CFM as basically one big switch statement and each CFCASE contains the information on what to do for a particular fuseaction. Therefore, the EXPRESSION= parameter of the CFSWITCH will be equal to your Fuseaction variable. An example: fuseaction=search might run a search and then display the results. In this case, the opening CFSWITCH statement should assign #FUSEACTION# to be the variable to be used, as in:
This means that basically, a fuseaction is the equivalent of a single CFCASE statement in your INDEX.CFM. Have a look at this code:
Suppose a user clicks on the following link:
Using the example code above, when ColdFusion executes our CFSWITCH using the “registration” fuseaction, it will first display our HTML header block, then it will include the registration form itself and then finally the HTML footer. The rest of the CFCASES will be ignored.
Article Inspired from : fusionauthority