PHPFB41 is in beta... w00t!

This is a MASSIVE improvement to the groundwork laid out in the
Fusebox 4 core files. You should feel free to report any bugs within the SF environment.
Again, please restrict your suggestions/feedback to keep the
functionality of the core files in line with the features that exist
for the CFMX version. Compatibility is the number one requirement here
to have these files accepted as "official"

Here is a changelog from JCQ:

IMPLEMENTED-by popular request, the standard FB <include> verb now can
save its target content to a content variable in the same way as the
<do> verb. Note that an <include> that specifies a contentvariable
with "overwrite=false" means that even the include itself will not
occur if the specified contentvariable already exists. As in <do>
overwrite=TRUE and append=FALSE are the defaults

IMPLEMENTED-"one-stop" core files: install a given version of core
files in one spot and have your FB access them from anywhere in any
web root. Note: this feature is directly responsible for the increased
number of application.fusebox variables introduced in this version,
and in the requirement for FUSEBOX_APPLICATION_PATH (which see)

IMPLEMENTED- the local variable FUSEBOX_APPLICATION_PATH must now be
provided just before the call to the Fusebox runtime. This can be a
relative path from the web root (or a CF-mapping) to the location of
the application files/fuses/etc. The need for this variable is a
direct consequence of implementing the one-stop core files

IMPLEMENTED-addition of an optional variable, FUSEBOX_APPLICATION_NAME which is set in index.php before the runtime is included. Use this to load an alternate app_[appname].php file, so you can have multiple webroots connected to a single fusebox application.

DECLINED-addition of a "preRequest" plugin phase, and a corresponding
"postRequest" plugin phase. Note: "preRequest" would likely be
excluded from any use of other plugin phases' "shared variable space",
although this restriction would not apply to "postRequest". Thus,
"preRequest" would just cycle through a list of templates defined in
fusebox.xml.

IMPLEMENTED- in the fusebox.xml file, the <do> verb in
<globalfuseactions/> section of the fusebox.xml has been deprecated in
favor of <fuseaction> which mimics its functionality completely. This
section of fusebox.xml allowed use of ONLY <do> verbs and the special
rule confused many developers. The <do> and <fuseaction> in
<globalfuseactions/> will operate interchangably in FB4.1 so that your
existing FB4.0 apps don't break, but the <do> will be dropped in some
future release. The <do> verb continues to operate as normal in
circuit.xml files

IMPLEMENTED-addition of a application-wide template "fusebox.init.php"
which loads at the top of every request. It runs after form/url
variables are copied to attributes scope and after completion of the
Loader, but before the default fuseaction is applied. This file can be
a helpful substitute for application constants and has full access to
the entire application.fusebox structure. Depending on your app it may
replace much of the need for the "Globals" preProcess plugin common in
so many FB4 applications, at least in terms
of your actual Fusebox app.

IMPLEMENTED-addition of a new fusebox parameter of "ignoreBadGrammar".
If TRUE (default), the core file will ignore any unknown (or poorly
formatted) verbs encountered during parsing; if FALSE, it will through
a Fusebox exception, which can be caught and dealt with via a
developer-defined error template.

IMPLEMENTED-addition of new Fusebox verbs of "instantiate" and
"invoke", which make working with CFCs or java classes easier. (Note:
this also makes Fusebox an excellent skeleton framework for
Flash-based OO apps without the overhead of an OO framework.) The
instantiate/invoke combo can also be used for basic webservice calls.

IMPLEMENTED - a new section in fusebox.xml to define the availability
and type of classes that <instantiate> and <invoke> can work with

IMPLEMENTED-each circuit in the application.fusebox.circuits structure
now has a "timestamp" key, similar to application.fusebox.timestamp.

IMPLEMENTED-the local myFusebox.params structure now has entries to
track whether the request is operating under user-inputted values for
Load, Parse, and Execute. These are named
myFusebox.params.userProvidedLoadParameter,
myFusebox.params.userProvidedParseParameter,
myFusebox.params.userProvidedExecuteParameter. These default to FALSE
unless the user provides a value.

IMPLEMENTED - the application.fusebox.rootdirectory has been
deprecated in favor of the new application.fusebox.approotdirectory,
and its twin application.fusebox.webrootdirectory.

IMPLEMENTED- there are some new application.fusebox entries:
application.fusebox.CoreToAppRootPath which gives the relative path
from the core files to the root of the application, and its complement
application.fusebox.AppRootToCorePath. Likewise added was
application.fusebox.CoreToWebRootPath which gives the relative path
from the core files to the web root of the application (typically
where "index.php" is located), and its complement
application.fusebox.WebRootToCorePath.
application.fusebox.WebRootToAppRootPath is a relative path from
index.php to fusebox.xml, and should be set in any include()s by plugins
accessing files not in the /plugins folder.

IMPLEMENTED- The new application.fusebox.isFullyLoaded is a boolean
which reflects whether the Loader successfully completed and
application.fusebox.dateLastLoaded holds a timestamp of when that occured

IMPLEMENTED-there is a new application.fusebox.errortemplatesPath
which points to the relative directory from the Root containing the
error templates for handling core file errors. It is fixed as
"errortemplates/"

IMPLEMENTED- a zero-length fuseaction is now treated the same as if it
were undefined, rather than throwing a "malformedFuseaction" exception

DECLINED/POSTPONED-expansion of the "circuit.fuseaction" nomenclature
to "fusebox.circuit.fuseaction". This would allow fusebox apps to be
dropped into other fusebox apps without having to be re-wired when the
subordinate app contains a circuit with the same alias as the larger app.

IMPLEMENTED-assertions for Fusebox. By default, Assertions are ON in
development mode, and OFF in production mode (unless you change the
fusebox.xml parameters "useAssertionsInProduction" and
"useAssertionsInDevelopment"). Parsed fuseactions result in a parsed
file with assertions and another without. The corefiles will use the
asserted parsed file in development mode if it find one, else it will
use the unasserted parsed file. In Production mode, only the
unasserted parsed file can be executed.

IMPLEMENTED-Make which version of each core file be reflected in its
file name. The version of the Runtime core file executes only Loader,
Transformer, and Parser core files of the same version. Throw a new
error of fusebox.missingCoreFile as needed. The Core files also make
use of two UDFs ("canonicalpath__()" and "relativeFilePath__()") which
have been extracted out of the core files and use the
double-underscore to ensure they don't step on your own UDF toes. We
thank Massimo Foti and Barney Boisvert, respectively, for contributing
these UDFs.

IMPLEMENTED-- in fusebox.xml, if the "parent" or "path" attribute in a
circuit definition is omitted, it is assumed to be the empty string

IMPLEMENTED-If the "parsed" or "plugins" directory doesn't exist off
your application's root, the Fusebox core file will attempt to create
it for you.

IMPLEMENTED-User-defined lexicon of verbs. Developers can write their
own customized verbs to be read by the parser, existing in their own
verb namespace. Don't like how <set> currently works? Write you own,
such as <jcq.set>. Have an idea for a new verb? Write your own such as
<jcq.pick object="nose">. Developers use this feature at their own
risk and can use the new "allowLexicon" boolean fusebox parameter to
determine if such verbs should be allowed and the badGrammar boolean
fusebox parameter to decide what to do with them. Developers must be
familiar with how the Parser core file handles verbs to take advantage
of this feature.

IMPLEMENTED-Fusebox core file errors (of type "fusebox.*") can be
caught by error templates. These should exist in a directory named
"errortemplates" off the root of app, and are name after the error to
which they correspond. Example: "fusebox.undefinedFuseaction.php" If
the error template does not exist, then Fusebox will throw the error
normally, as in FB4.0
A list of possible fusebox core file errors types is below:

Custom Error can be thrown from core file:
------------ ----------------------------
fusebox.missingCoreFile runtime
fusebox.malformedFuseaction runtime
fusebox.undefinedCircuit runtime
fusebox.undefinedFuseaction runtime
fusebox.invalidAccessModifier runtime
(formerly "fusebox.AccessModifier")
fusebox.errorWritingParsedFile runtime
fusebox.missingParsedFile runtime
fusebox.missingAppPath runtime

fusebox.missingFuseboxXML loader
fusebox.fuseboxXMLError loader
fusebox.missingCircuitXML loader
fusebox.circuitXMLError loader

fusebox.undefinedCircuit transformer
fusebox.undefinedFuseaction transformer
fusebox.overloadedFuseaction transformer
fusebox.invalidAccessModifier transformer

fusebox.missingFuse parser (actually it is the parsed
file that will throw the error, at execution)
fusebox.failedAssertion parser (actually it is the parsed
file that will throw the error, at execution)
fusebox.badGrammar parser