Fusebox: An Overview (Part II)
The Logical Setup of A Fusebox application
In Part I of this article, you learned about physically setting up your Fusebox application, and how your code must be broken down into small modular pieces. Now, let's look at the coding logic of a Fusebox app.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 Fuseaction
The 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://www.this.co.uk/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:
<FORM action="INDEX.CFM" method="post">
<input type="hidden" name="fuseaction" value="search">
</FORM>
|
Okay, so now you are probably wondering about the internal workings of the INDEX.CFM file. As mentioned earlier, 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:
<CFIF my_variable is "DOG">
"Wooof"
<CFELSEIF my_variable is "CAT">
"Meeooow"
<CFELSEIF my_variable is "COW">
"Moooooo"
<CFELSE>
[[Silence]]
</CFIF>
|
Using CFCASE/CFSWITCH, the same statement would be:
<CFSWITCH EXPRESSION="my_variable">
<CFCASE VALUE="DOG">
"Wooof"
</CFCASE>
<CFCASE VALUE="CAT">
"Meeooow"
</CFCASE>
<CFCASE VALUE="COW">
"Moooooo"
</CFCASE>
<CFDEFAULTCASE>
[[silence]]
</CFDEFAULTCASE>
</CFSWITCH>
|
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:
<CFSWITCH EXPRESSION="#FUSEACTION#"> |
This means that basically, a fuseaction is the equivalent of a single CFCASE statement in your INDEX.CFM. Have a look at this code:
<CFSWITCH expression="#fuseaction#">
<CFCASE value="Sign_Up_For_Newsletter_Form">
<CFINCLUDE template="/public/Main/blocks/dsp_html_header.cfm">
<CFINCLUDE template="/public/Newsletter/blocks/dsp_registration_form.cfm">
<CFINCLUDE template="/public/Main/blocks/dsp_html_footer.cfm">
</CFCASE>
<CFCASE value="Register_User_For_Newsletter">
<CFINCLUDE template="/public/Newsletter/queries/qry_check_for_dups.cfm">
<CFINCLUDE template="/public/Newsletter/blocks/dsp_registration_thank_you.cfm">
<CFINCLUDE template="/public/Main/blocks/dsp_html_footer.cfm">
</CFCASE>
</CFSWITCH>
|
Suppose a user clicks on the following link:
<a href="INDEX.CFM?fuseaction=Sign_Up_For_Newsletter_Form">Sign up for the newsletter</a> |
Using the example code above, when ColdFusion executes our CFSWITCH using the "Sign_Up_For_Newsletter_Form" 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.
Are you still with me? Great, because now you?ve already got down most of the basics of a Fusebox application. In part III of this article, we will cover some of the finer points of writing a good Fusebox application.