Compatibility
The goal of Fusebox 5 is that all Fusebox 4.1 applications and almost all Fusebox 4.0 should run unchanged with the new core files. Most plugins written for Fusebox 4.x should run identically on Fusebox 5.
To upgrade 4.x Framework versions, you will need to follow the Fusebox Installation instructions. The only real change needed to your code files will be within your index.cfm file to execute the new Core files as follows:
Known Compatibility issues that you may need to be aware of:
- Many of the structures in Fusebox 4.x have become objects in Fusebox 5. Those objects have public data members wherever the equivalent structures in Fusebox 4.x had documented keys so most applications will be completely unaware of this change. In particular, myFusebox and application.fusebox are objects and so are things like circuit, fuseaction, plugin and class (i.e., class definition, from the <class> declaration in fusebox.xml).
- In application.fusebox, Fusebox 4.x exposes a series of underlying XML objects as part of the structure. These are no longer available. Fusebox 4.x manipulated the XML object in-memory in order to transform the raw XML into the actual structure that is translated. Fusebox 5 does not work the same way: the XML is read in and a new CFC-based object model is built directly from the original XML. The specific structure keys that are no longer offered in Fusebox 5 are:
- application.fusebox.xml
- application.fusebox.globalfuseactions.*
- application.fusebox.circuits.*.xml
- application.fusebox.circuits.preFuseaction.*
- application.fusebox.circuits.postFuseaction.*
- application.fusebox.circuits.*.fuseactions.*.xml
- Assertions are not implemented.
- There is no fuseQ and almost all of the fb_ structure has gone away. The former was never documented. The latter was documented as existing but clearly flagged as something developers should not use. The only valid use of the fb_ structure in Fusebox 5 is for the fb_.verbInfo structure provided to custom verbs. In particular, this will break some Fusebox 4.1 custom lexicons (that were not using the fb_*() methods appropriately).
- Several of the Fusebox <parameter> values that dealt with the code generation (in the parsed/ directory) no longer have any impact. Setting these is not an error, even in strict mode, but might well become an error in a future release of Fusebox. Here is a list of ignored parameters:
- osdelimiter - always set to "/" on every platform
- parseWithComments - ignored
- parseWithIndentation - ignored
- ignoreBadGrammar - ignored
- allowLexicon - ignored (lexicons are core to the framework now)
- useAssertions - ignored (assertions are not implemented)
- conditionalParse - ignored
- scriptLanguage - ignored (the core files have never been able to generate more than one language)
- Boolean attributes on verbs must be either true or false. Fusebox 4.1 allowed anything that evaluated to a boolean in a couple of places (notably in the <relocate> verb's addtoken attribute). Consider those to be bugs in Fusebox 4.1 that have been fixed!
- The <class> declaration no longer requires the type attribute. If you omit it, it defaults to "component".
- fusebox.init.cfm is executed before attributes.fuseaction is defaulted in Fusebox 4.1 but after in Fusebox 5. Some magic happens to ensure this does not affect any processing done by fusebox.init.cfm but it means that, going forward, fusebox.init.cfm can (and should) rely on the presence of attributes.fuseaction, which was not true in Fusebox 4.1.
- Fusebox 5 reserves the structure request.__fusebox for certain purposes during compilation and runtime. This structure should not be modified.
Fusebox 3
Sean Corfield has stated: "Fusebox 5.7 will be able to execute Fusebox 3 applications." Which, as of this writing, has yet to be released.
For those in needing to upgrade their applications from Fusebox 3 to a more current version, you may use Steve Nelsons Fusebox 3 to Fusebox 4 version converter. This code base has been setup on Google Code for peremanant linkage, accessible here.