Brian Kotek has a neat cfc to re-generate the Fusebox parse files. It could be the start of a FB4 version of Barney's Fusedocer?

To ensure that a fusebox is completely cleared, put his code in the fusebox.init.cfm file.

<!------------------------------------------------------------------------------
    if the app is to be reset a password is also required
------------------------------------------------------------------------------->
    <cfif NOT StructKeyExists(application,"isApplicationAlive")
            OR (url.reset AND url.password EQ application.fusebox.password)>

<!------------------------------------------------------------------------------
    clear out the parsed directory
------------------------------------------------------------------------------->
        <cflock scope="application" type="exclusive" timeout="3000">
            <cfset strParseDirectory = "#application.fusebox.rootdirectory#parsed">
            <cfset StructDelete(application,"fusebox")>       

            <cfdirectory action="list"
                name="rstParseDirectory" directory="#strParseDirectory#" filter="*.cfm">

            <cfloop query="rstParseDirectory">
                <cffile action="delete" file="#strParseDirectory#/#rstParseDirectory.name#">
            </cfloop>
        </cflock>
</cfif>

Sean Corfield (as usual) has detailed the way FUSEBOX_APPLICATION_PATH works.

An interesting thread on the Fusebox forum discussing the difference between DAO and DTO.

Another hat tip to John Beynon.
Here's a link to his "Learning Fusebox" blog category.

Another interesting posting by John Beynon. This time on frameset and FB4.1 which is of current interest.
I thought I'd got a good handle on FB framesets, but it's alway good to have a second opinion!

Here's a PHP Wiki on the FB4 core files etc.

Hey, this was me!

"The exact order of execution of various phases and plugins in Fusebox 4.1".

1. fusebox.init.cfm - note that this cannot output anything!
2. preProcess plugin phase - for the entire request
3. preFuseaction plugin phase - for global preprocess fuseaction
4. globalPreprocess - the actual fuse for a global preprocess fuseaction
5. postFuseaction plugin phase - for global preprocess fuseaction
6. preFuseaction plugin phase - for the main fuseaction
7. mainFuse - the fuse invoked by the requested fuseaction
8. postFuseaction plugin phase - for the main fuseaction
9. preFuseaction plugin phase - for global postprocess fuseaction
10. globalPostprocess - the actual fuse for a global postprocess fuseaction
11. postFuseaction plugin phase - for global postprocess fuseaction
12. postProcess plugin phase - for the entire request