• Home
• Tutorials
• Forums
• Reference
• Developers
• Advertise
• About Us

Turning up the heat in Fusebox 4.1

Notice: Please read my other tutorials Fusebox 4.1 for beginners part 1-4 before attempting this tutorial.

Introduction:

We are going to be turning up the heat in how we organize and implement our fusebox 4.1 applications. In my original tutorials you learned the basic in’s and out’s of the Fusebox framework and how the framework allows for smaller pages of code and easier security.

This tutorial will show you some methodologies and xml tags that you can use in your fusebox applications to better achieve organized code snippets and take advantage of Fusebox 4.1’s power as a application framework. You will need my sample application loaded onto your testing server to follow along. Click here to download it.

Organization being your best friend (acceptable methodologies when building fusebox applications):

Fusebox has its do’s and don’ts that should be practiced by all using the application framework. Now these are not official by any means rather an opinion of mine. And though they are very good practices your experience with fusebox and your coding habits may differ from mine. So please do not write me hate mail or egg my house or anything. :) Ok that said lets start by opening the sample application and taking a look at the structure.

Folders man’s other best friend:

As you gaze glassy eyed at it notice anything different about my structure compared to the prior tutorials where we stuck all our files into the folder along side the fusebox.xml file and index.cfm file. Open up the folder named “Main” you will find 3 subfolders inside along with a circuit.xml.cfm file. You should be looking at something similar to figure 1.0 below.

Figure 1.0

As you can probably figure out the “actions” folder is for pages we prefix with act_ the “displays” folder is for our pages we prefix with dsp_ and our “queries” folder is for our files we prefix with qry_. This structure makes for an easy way to find files we need to alter in any way, plus it puts our code into neat and tidy packages. I also name my main folders the same as the circuit name in fusebox.xml. Meaning that if I have defined a circuit in fusebox.xml file of “Dill” I make a folder named “Dill” and set it up with subfolders actions, displays, and queries and place my circuit.xml.cfm file inside the parent folder of “Dill”.

Again I repeat these are my methodologies and they are not official by any stretch of the imagination, but they do make sense. As well as folders you will find that you can have a parent/child relationship with your circuits. Take a look at the main folder where I have a folder named “Register” along side the actions, display, and queries folders as shown in figure 1.1 below.

Figure 1.1

 

Now go ahead and open the fusebox.xml file and take a look. I’ve listed the circuit of “Register” with a parent of “Main” and did the path as follows main/register/. Pretty cool huh? That little feature leaves the door open to a wide range of complex structures. Allowing you complete control over your folders and subfolders. Thus the reason for my teaching you my methodology on file structure in fusebox. Could you imagine hundreds of pages stuffed into the root application folder? It sends chills down my spine just thinking about it!

Comments will lead to your salvation:

Trust me when I say this and those of you who have worked on projects before will know this all to well. Comment your code! For the xml files (including circuit.xml.cfm) you would use the following format:

      <! - -Your Comment - ->

For cfml pages:

     <! - - - Your Comment - ->

The reason I bring this up is because fusebox application (applications built on fusebox) can get quite large and complex. Simple commenting in your circuit.xml.cfm files and all your files will not only help you, but may save you hours upon hours trying to find the fuseaction or circuit that went bad. I’ve created a pretty basic snippet of code for both Coldfusion and xml that should be used as a header for all your pages. You’ll find them in the folder called snippets.

The XML built into the Fusebox 4.1 Framework

The xml in fusebox is a new item and venture from previous fusebox frameworks. In Fusebox 3 a cfswitch tag on a page did all the work that the circuit.xml.cfm does now. What was wrong with cfswitch? Scalability. The word that will haunt you as a developer till the day the earth stands still. People were building massive cfswitch statements with hundreds of lines of code and variables with no end in site. The Fusebox developers decided that this was not going to do and set to work to construct a framework that allowed for scalability and do away with heavy processing done by the Coldfusion server. They looked high and low and found xml their redeemer, and set to work using coldfusion’s love of xml. Xml being a very easy tag based language to read and Coldfusion being one of the best application languages to use seemed like a perfect fit.

So the developers toiled night and day and came to the people with Fusebox 4.1 in hand. Yet that wasn’t all not only did they bring back a more efficient way of creating scalable applications, but they brought back xml tags to use as you would their counterparts in cfml. And they all lived happily ever after… Ok so most of the story was true.

Fusebox 4.1 introduced xml and with it the xml tags we are going to discover now.

The <if> tag:

You probably guessed without much prompting that the counterpart of this xml tag is <cfif>, and you would be correct. The <if> tag is built into fusebox and allows you to use it without any special code or configuration. The <if> tag structure looks as follows:

<if condition="[condition statement]">
    <true>
        Do, include, or relocate
    </true>
    <false>
        Do, include, or relocate
    </false>
</if>

So can you see the potential in this tag? Believe it or not you can use conditional statements in this tag as you would the <cfif> tag. Take for example below:

<if condition= "IsDefined('session.pass') AND #Session.pass# EQ 'ok' ">
    <true>
        <include template="displays/dsp_usergood.cfm" />
    </true>
    <false>
        <include template="displays/dsp_userbad.cfm" />
    </false>
</if>

As far as I am aware, and I stress this statement I do not know of any of the conditional statements that is freely used in the <cfif> tag that doesn’t work with the <if> tag. If haven’t tried the thousands of combinations of conditional statements and I am not about to so be leery if there is a statement that doesn’t work let us know, but please don’t say that I said all the conditional statements work. Like I said before as far as I know they do.

Ok that brings us to the next xml tag introduced in Fusebox 4.1.

The <do> Tag:

The <do> tag is by far the coolest bad boy of all the xml tags in my opinion. This tag will more than likely become your favorite. Especially if you want things to run in the background or want to use templates in your application. The <do> tag offers you the power to call another fuseaction from anywhere in your fusebox application to the fuseaction it is calling from. In simplest terms it is like the <cfinclude> tag only far more powerful and much easier to use in fusebox. The basic format for the <do> tag is as follows:

    <do action="[fuseaction] or [circuit.fuseaction]" />

It’s that simple. Isn’t it great?! Open up the circuit.xml.cfm file for the register circuit and take a look at the fuseaction named “Act_Register”. You will find the <do> tag being used in an unusual way. I did this to show you how powerful this tag is. The do action attribute is set to Members. Act_Register. (Heaven choir singing…. and stop) Now you have an idea of the possibilities from template displays through security. Along with the “internal” access of the fuseactions as observed when you open the circuit for members.

The <loop> Tag:

The <loop> tag allows us to do a conditional loop. Like the <if> tag you can not nest them. Again as far as I know you can use any condition you would use in a cfloop tag.
A working example is found in the Non_members circuit.xml.cfm file, when you choose just to visit you will see it in action. The format for the <loop> tag is as follows:

    <loop condition="[some condition]" / >
        Some task to perform
    </loop>

Pretty easy huh? You could use this to loop a list, loop a session, loop just about anything before a fuseaction is displayed.

The <relocate> Tag:

The relocate tag works similar to the cflocation tag. It allows you to relocate the user to another place when a fuseaction is called from inside that fuseaction before the page even displays. The <relocate> tag also can hold a token. Pretty cool, huh? The format is as follows:

    <relocate url="[some url]" addtoken="some token]" />

You do not need the addtoken attribute to pass the tag and you must state the url as you would with cflocation you can not just call a fuseaction.

Conclusion:

Now that you have a sample of a fusebox application and have learned a good portion of the xml tags available to fusebox users you can create complex and easy to use applications of your own. I look forward to seeing them.