Table of Contents

  1. Welcome to the Fusebox Project Wiki
    1. Bug Tracker
    2. History
    3. Team Fusebox and TeraTech
  2. Documentation Overview
    1. Frequently Asked Questions
  3. Understanding the XML Files
    1. What are the Fusebox XML files?
    1. The fusebox.xml File
    1. The circuit.xml file
      1. circuit
      2. fuseaction
      3. prefuseaction, postfuseaction
  6. Circuit XML Grammar
    1. Overview
    2. The Builtin Verbs
    3. Gotchas
    4. Summary
  7. Extending the FB5 framework with Custom Lexicons
    1. What’s happening here?
    2. Built-in Verbs
    3. Writing Custom Verbs
    4. Example verbs
      1. <cf:abort>
      2. <cf:dump>
  8. Extending The FB5 Framework With Plugins
  9. FLiP Methodology Overview
  10. Fusebox 5.1 Release Notes
    1. Bugs fixed in Fusebox 5.1
    2. Enhancements added in Fusebox 5.1
    3. Other miscellaneous tickets closed in Fusebox 5.1
  11. Fusebox 5.1 Enhancements
    1. Globally Shared Files
      1. Globally Shared Circuits
      2. Globally Shared Plugins
      3. Globally Shared Error Templates
      4. Globally Shared Lexicons
    2. Search Engine Safe URLs
    3. Using event as an alternative to attributes

Extending The FB5 Framework With Plugins

::TODO:: Complete documentation on Plugins. Below are the changes in FB5.

Although nothing has really changed in this area of the framework - most Fusebox 4.1 plugins should continue to work with Fusebox 5 without any changes - there are two changes that will impact the lives of plugin authors:

  • The parsed XML is no longer available as part of the application.fusebox structure
  • There are a number of "convenience" methods in the myFusebox object

The former change will break some advanced plugins. Sorry. I just don't think the framework itself should have exposed those XML fragments and, with the revised compilation engine in Fusebox 5, the framework does not actually break the XML down the same way so it would actually be difficult to expose the same specific XML fragments that Fusebox 4.x exposed. However, in order to make it relatively easy for a plugin to find out the directory path and filename for the XML files, convenience methods are available on the fuseboxApplication and fuseboxCircuit objects.

Turning to the myFusebox object, there are the following convenience methods which may be useful to plugin authors:

  • getApplication() - returns the fuseboxApplication object that represents the application
  • getCurrentCircuit() - returns the fuseboxCircuit object that represents the currently executing circuit (if applicable)
  • getCurrentFuseaction() - returns the fuseboxAction object that represents the currently executing fuseaction (if applicable)

These methods are just shorthand for accessing the follow data respectively:

  • application![FUSEBOX_APPLICATION_KEY]
  • application![FUSEBOX_APPLICATION_KEY].circuits![myFusebox.thisCircuit]
  • application![FUSEBOX_APPLICATION_KEY].circuits![myFusebox.thisCircuit].fuseactions![myFusebox.thisFuseaction]

Locating the XML files is possible using these method calls on the myFusebox object:

  • myFusebox.getApplication().getApplicationRoot() & myFusebox.getApplication().getFuseboxXMLFilename() - returns the full filesystem path of the fusebox.xml (or fusebox.xml.cfm) file for this application
  • myFusebox.getCurrentCircuit().getCircuitRoot() & myFusebox.getCurrentCircuit().getCircuitXMLFilename() - returns the full filesystem path of the circuit.xml (or circuit.xml.cfm) file for the currently executing circuit

If a plugin needs to loop over all the circuit objects, it can do the following:

  • <cfloop collection="#myFusebox.getApplication().circuits#" item="circuitName">

All of the public methods in the various framework objects are documented (using the hint attribute) so that plugin authors can take advantage of all of the exposed framework functionality. View the automatically generated documentation.