Additional Information on XFA

Instead of trying to edit the original XFA entry (I lack the energy right now) I am adding a copy from the Fusebox forums that I beleive give an excellent explaination and use case for XFAs

This is the circuit xml, all your fuseactions look like this. The xml you put here gets written into CF (or PHP) automatically by the core files into a "parsed" version of your fuseaction.

XFA stands for "eXit FuseAction". Basically, any exit from a fuseaction that has a viewable component, if that exit is to another fuseaction in your application it should be parameterized into an XFA, instead of being hard-coded into your display code. Using the above example, you would go from this:

to

There are some very real benefits to doing this.

1. Your display fuses become easier to maintain. If you were to change the gateway page from "index.cfm" to "go.cfm" for example, every one of your hard-coded links and form actions would have to be changed inside your display fuses. Since we're using #myFusebox.getMyself()# here it actually protects us against both changes to your gateway page, and also changes to the name of your fuseaction variable. In your fusebox.xml file you could change the parameter "self" to have a value of "go.cfm", and the parameter "fuseactionVariable" to have a value of "method", and all you'd need to do is add &fusebox.loadclean=true to your querystring one time to refresh all of your parsed fuseaction files, instead of needing to rewrite each individual display fuses. The same goes for the use of XFAs instead of putting in the actual value of the fuseaction in the link or form action. If you need to change the name of a circuit or fuseaction for any reason, you don't want to have to change your display code, when you could just change the value of the XFA in your circuit code.
2. Your display fuses become more portable and thus reusable, and you therefore get away with using less code to write your application. Take for example an admin form that lets you edit a member's info. Using XFAs you can use the form for both adding and editing a fuseaction:

Here's the code for dsp_member_adminform.cfm:

Using the code above, this form page is now completely insulated from any need for knowledge of the application, it runs using the parameters passed into it. If those parameters change then the output will change but you won't need to update the code on the form page. And, since I'm passing in the query "member_byid" to both fuseactions, This form is now usable for both fuseactions. In the case of the addform fuseaction the values of member_byid.MemberFirstName and MemberLast name will both be empty, so it will be a blank form. In the case of the editform fuseaction the data in the form is populated. And there you go! Two fuseactions for the price of one!