Fusebox 5.1 Enhancements

This page documents the major enhancements in Fusebox 5.1

Globally Shared Files

Circuits, plugins, errortemplates and lexicons can all be shared across multiple Fusebox applications because you can specify absolute paths, i.e., that begin with a "/" so they are webroot-relative or resolved via a ColdFusion mapping.

Globally Shared Circuits

By default, circuits paths are relative to the application root. With Fusebox 5.1, you can now specify a new attribute on a declaration in fusebox.xml that specifies whether a circuit path is relative or not (i.e., absolute or mapped). The default is relative="true". If you specify relative="false" and your path= attribute begins with a / then the circuit path will be treated as absolute (relative to your server's webroot) or mapped (resolved via a ColdFusion mapping).

Globally Shared Plugins

When you declare a plugin, you can specify a template name and, optionally, a path that is relative to the plugins subdirectory of your application root:

This tells Fusebox to look for plugin_page.cfm in the plugins/relative/ subdirectory of the application root.

With Fusebox 5.1, you have several new options:

You can specify an absolute (or mapped) path= attribute.
You can specify an absolute (or mapped) template= attribute (in some ways this is equivalent to the path= attribute),
You can override the default pluginsPath for the entire application.
You can either specify a relative path:

or an absolute (or mapped) path:

If you specify a relative path= attribute and relative template= attribute in a plugin declaration, they are relative to the pluginsPath parameter.

Globally Shared Error Templates

By default, every Fusebox application has to have a copy of the error templates. With Fusebox 5.1, you can now override the location of the error templates by specifying the errortemplatesPath parameter in fusebox.xml. You can either specify a path relative to your application root or an absolute (or mapped) path:

This causes Fusebox to look in the sharederrors directory under the webroot or wherever the /sharederrors ColdFusion mapping points for any exception templates.

Globally Shared Lexicons

By default, lexicons are introduced with the xmlns declaration in a fusebox or circuit tag as a prefix and a path that is relative to the lexicon directory under your application root. With Fusebox 5.1, you now have two additional options:

You can specify an absolute or mapped path in the xmlns declaration.
You can override the default base directory for lexicons by specifying the lexiconPath parameter in fusebox.xml.

If you specify an absolute or mapped path in a xmlns declaration, that defines the complete path for the declared lexicon, e.g.,

xmlns:prefix="/sharedlexicon/mylexicon"

Either sharedlexicon is a directory under your webroot or /sharedlexicon is a mapping. Fusebox would look in the mylexicon directory under sharedlexicon. This allows you to override the default search path for a specific lexicon.

You can also override the default lexicon search location for the entire application by specifying lexiconPath within fusebox.xml. The default is lexicon/ which is a directory below the application root. You can either specify a different path relative to your application root such as:

or you can specify an absolute or mapped path:

In either of these cases, a relative path in an xmlns declaration is now relative to the lexiconPath location.

Search Engine Safe URLs

Handling of self, myself, and has been enhanced to allow you to specify how the URLs are constructed by the framework.

now allows child tags: can be used to specify URL parameter name / value pairs instead of specifying them directly in the XFA value. In other words, instead of saying:

you would now say:

This cleanly separates the actual XFA - the fuseaction - from the various URL parameters in the target URL.

For more information on Fusebox SES URL's, click here

Using event as an alternative to attributes

For developers who want a more object-oriented way to handle data that comes in from the URL and form scope, there is now an alternative to the attributes scope. An object called event is now available in the main variables scope with methods that allow you to get and set values within the underlying attributes scope.

The following methods are available on the event object:

Method	Arguments	Description
init	struct attributes	Used by Fusebox to create the event object as a shadow of the attributes scope.
getValue	string valueName, any defaultValue	Returns the named attribute value, or the specified default if no such value exists.
valueExists	string valueName	Returns true if and only if the named attribute exists in the attributes scope.
setValue	string valueName, any newValue	Sets the named attribute to the specified value.
getAllValues		Returns the attributes scope behind the event object.
removeValue	string valueName	Removes the named attribute from the attributes scope.

The event object is automatically created in the fusebox5.cfm file and is available in the main variables scope, just like the attributes structure. The intent is that event would be more idiomatic for use with a CFC-based model. It's full component name depends on the location of the Fusebox core files (it might be fusebox5.fuseboxEvent, for example) so developers should simply declare the argument type in their model component method to be type="any" and avoid direct dependence on the Fusebox path.

Quick Reference

Newest Pages

Recent Updates