ial size=-1 color=black>Yahoo! is not affiliated with the authors of this page or responsible for its content.
Fusebox 5.5 Alpha 2 Release Notes Wednesday, September 5, 2007 Fusebox 5.5 Alpha 2
Release Notes
Wednesday, September 5, 2007
Fusebox 5.5 Alpha 2 Documentation
Page 1 of 12 Table of Contents
Overview
3
Theme: Simplication
3
Theme: Extensibility
3
Making XML Optional
3
The simplest Fusebox application
4
FUSEBOX_PARAMETERS and omitting fusebox.xml
4
Omitting circuit.xml
5
Implicitly locating a circuit
5
CFCs as Circuits
6
Directories as Circuits
7
Fuseaction XML Files
7
CFML Templates as Fuseactions
7
CFCs as Fuseactions
7
Dynamic Do
8
Model-View-Controller w/out XML
8
The Event Object
9
Application.cfc Support
10
Additional Changes
11
Enhancements
11
Debug Trace
11
myFusebox.getApplicationData()
12
Bugs Fixed
12
Known Issues
12
Fusebox 5.5 Alpha 2 Documentation
Page 2 of 12 Overview
This is an evolving document that describes the new features in Fusebox 5.5 and will ultimately
be integrated into the main Fusebox documentation.
There are two primary themes to Fusebox 5.5:
1. Simplify. Remove barriers. Make it easier for newbies. Make building applications faster
by favoring convention over configuration.
2. Extend through extensibility. Provide new functionality outside the core. Add plugins,
lexicons, even standardized circuits.
In addition, backward compatibility is of paramount importance so all Fusebox 4.x and Fusebox
5.x applications should run, unchanged, on Fusebox 5.5. In theory, you can just unzip the new
core files over the top of your existing core files and everything should just work.
Theme: Simplication
According to the survey conducted early in 2007 by TeraTech, Inc., the main complaint about
Fusebox 4.x through Fusebox 5.1 is the use of XML to configure the application and to specify
the flow of control. Whether real or merely perceived, the use of XML appears to be the single
largest barrier to adoption of Fusebox. Accordingly, the primary focus of this theme for Fusebox
5.5 is to make the XML files optional for most use cases by adopting a set of reasonable defaults
and conventions. The Alpha allows you to build Fusebox applications without using XML, as
long as you follow a number of conventions in terms of file system layout and naming.
Theme: Extensibility
Fusebox 4.0 introduced a number of extension points into the framework that allow users to ex-
tend the behavior of the core files without needing to change the core files. Subsequent releases
have continued on this path with Fusebox 5.0 introducing lexicons as a way to extend the lan-
guage of Fusebox. Fusebox 5.5 now offers a standard set of extensions as a separate download
that includes: lexicons for ColdFusion-like verbs, ColdSpring, ORMs (Object Relational Map-
pings) for both Transfer and Reactor, and a more comprehensive lexicon for Reactor; plugins for
assertions; scaffolding for quickly generating basic data management applications.
Making XML Optional
Fusebox 4.x through Fusebox 5.1 use XML for two purposes:
1.
fusebox.xml
for configuring your application: setting application parameters and de-
claring classes, plugins and global fuseactions;
2.
circuit.xml
for specifying the logical flow of control for a given fuseaction.
Fusebox 5.5 Alpha 2 Documentation
Page 3 of 12 Within these XML files, many of the settings and/or attributes are already optional, with docu-
mented default values. In order to make the XML files themselves optional, another mechanism
must be provided to either override the defaults or specify values that cannot be defaulted. For
example, the default value for the fuseactionVariable is "fuseaction" but the default
value for the defaultFuseaction is "". Clearly the latter has to be overridden for all appli-
cations.
The simplest Fusebox application
Here is the classic Hello World! application in Fusebox 5.5 in the simplest possible form:
index.cfm:

<cfapplication name="helloworld" />

<cfset FUSEBOX_PARAMETERS.defaultFuseaction = "main.welcome" />

<cfset FUSEBOX_PARAMETERS.allowImplicitFusebox = true />

<cfinclude template= "/fusebox5/fusebox5.cfm" />
main/welcome.cfm:

Hello World!
This simple, two file application displays
Hello World!
with no XML. The circuit
main
is
resolved to the directory
main/
and the fuseaction
welcome
is resolved to the fuse
welcome.cfm
.
The following sections explain in more detail how you can build Fusebox applications without
XML and what options you have for structuring your code.
FUSEBOX_PARAMETERS and omitting fusebox.xml
Fusebox 5.5 introduces a new top-level variable called
FUSEBOX_PARAMETERS
which is a struc-
ture that you can use to specify parameters that would normally be set in the
<parameters>

block inside
fusebox.xml
. You can use this in your
index.cfm
file to specify parameters,
prior to including the core file entry point:
<cfset FUSEBOX_PARAMETERS.defaultFuseaction = "controller.welcome" />
<cfset FUSEBOX_PARAMETERS.debug = true />
These values will override any matching
<parameter>
settings in
fusebox.xml
whenever the
Fusebox application is reloaded.
Fusebox 5.5 also introduces a new parameter setting,
allowImplicitFusebox
, which allows
the
fusebox.xml
file to be omitted. Naturally, this has to be set in
index.cfm
:
<cfset FUSEBOX_PARAMETERS.allowImplicitFusebox = true />
When this is specified as
true
, the
fusebox.xml
file may be omitted and Fusebox uses default
values for all settings that are not explicitly specified in the
FUSEBOX_PARAMETERS
structure in
index.cfm
.
Fusebox 5.5 Alpha 2 Documentation
Page 4 of 12 If you omit the
fusebox.xml
file, the only settings that will be active will be those specified in
the
FUSEBOX_PARAMETERS
structure and any standard Fusebox defaults for settings not speci-
fied in that structure.
Omitting circuit.xml
Fusebox 5.1 introduced the parameter setting,
allowImplicitCircuits
, so that you could
omit the
circuit.xml
file for a circuit that is used only as a container for fuses that are in-
cluded by other circuits (via the
<include>
verb with the
circuit=
attribute). In such a situa-
tion, the
circuit.xml
file, if present, would be empty anyway, containing only
<circuit/
>
, possibly with an
access=
attribute.
Fusebox 5.5 extends the meaning of
allowImplicitCircuits
to also indicate that circuit
declarations can be omitted completely. If you omit
fusebox.xml
, you have no circuit declara-
tions and so
allowImplicitCircuits
is automatically set to true. If
fusebox.xml
is present
but you wish to omit the circuit declarations, you must explicitly set
allowImplicitCir-
cuits
to true.
Implicitly locating a circuit
If you attempt to execute a fuseaction in a circuit that is not declared, Fusebox 5.5 attempts to
deduce the location and form of the circuit using a series of conventions. As of this writing,
Wednesday, September 5, 2007, these conventions are in draft form and apply to the current Al-
pha. Based on feedback from the Fusebox community, these conventions may change before the
final release.
Fusebox 5.5 first attempts to find a regular
circuit.xml
(or
circuit.xml.cfm
) file by look-
ing in the following locations relative to the application root (assuming a fuseaction of
alias.action):

controller/alias/

model/alias/

view/alias/

alias/controller/

alias/model/

alias/view/

alias/
If a circuit file is found, it is treated as a regular Fusebox circuit that simply was not declared in
fusebox.xml
. Otherwise, Fusebox attempts to find a CFC that represents the circuit by looking
for:

controller/alias.cfc [access="public"]

model/alias.cfc [access="internal"]
Fusebox 5.5 Alpha 2 Documentation
Page 5 of 12
view/alias.cfc [access="internal"]
If such a CFC is found, it is treated as a circuit with the methods representing fuseactions see
below. Otherwise, Fusebox looks for matching directories:

controller/alias/ [access="public"]

model/alias/ [access="internal"]

view/alias/ [access="internal"]

alias/ [access="public"]
If such a directory is found, it is treated as a circuit with the files within that directory represent-
ing fuseactions see below. Otherwise, Fusebox throws an exception that the requested circuit is
undefined.
Whilst this may seem like a complicated set of rules, it is intended to support the most common
conventions used today in Fusebox applications (and, in fact, in several other frameworks). The
intent is that Fusebox should be intuitive to use without having to think about the rules: the
common conventions should just work.
The first searches for
circuit.xml
files are intended to support common Fusebox conven-
tions in the absence of a
fusebox.xml
file. The remaining searches are intended to support a
more object-oriented approach (CFCs-as-circuits) or a simple procedural approach (directories-
as-circuits). This is in line with Fusebox's goals of supporting a wide range of programming
styles while not getting in the way of the programmer.
CFCs as Circuits
If Fusebox identifies a ColdFusion Component as a circuit, it expects to be able to call methods
on that CFC corresponding to fuseactions within the specified circuit. If a request is made for
alias.action and Fusebox determines that
alias.cfc
is the specified circuit, then the following
method should exist in that CFC:
<cffunction name="action" returntype="void" access=