-----------------------------
Fusebox 4.1  changelog 
-----------------------------
v 4.1.0 (official release 12/31/2004)
====
-IMPLEMENTED - content variables now support the "prepend" attribute. It works just like "append" but prepends any newly generated content in front of any existing content. As with "append", "prepend" is FALSE by default. You can prepend and append at the same time.

-IMPORTANT NOTE:  if you were involved with the FB4.1 beta, you'll recall that the <class> section of fusebox.xml can deal with constructors for both ColdFusion Components (CFCs) as well as for Java classes. When the class in question is later <instantiate>'ed, a Java class will automatically have its constructor called. A CFC will only have its constructor called if you specify it. In early versions of the FB4.1 beta, a constructor of "init" was assumed to exist if you did not specify a CFC's constructor. That has changed. Since CFCs do not automatically call their constructor when instantiated, it was decided that FB should not do anything automatically either when instantiating a CFC. Therefore, unlike earlier beta versions, a CFC constructor will only be called upon instantiation if and only if you've already specified the constructor method in the <class> tag. Most developers familiar with the beta cores will not encounter any problems, and the few that do will benefit from simply being explicit in your <class> definitions with regard to constructor methods

v 4.1.0beta002:
====
IMPLEMENTED - the core files have changed their names to only contain the major version number ("4" currently), rather than both the major and minor version numbers.

IMPLEMENTED - DTDs for both fusebox.xml and circuit.xml are now included in the core file distribution.

v 4.1.0beta001:
====
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 - by popular request, the standard FB <loop> verb now support looping over a query as well as a counting loop

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 (see below)

IMPLEMENTED - the local variable FUSEBOX_APPLICATION_PATH  must now be provided just before the call to the Fusebox runtime. This is the relative path from the web root (where index.cfm is) to the location of the application files (fusebox.xml, fuses, circuits, etc)  The need for this variable is a direct consequence of implementing the one-stop core files

IMPLEMENTED - optional conditional regeneration of the parse file in development mode.  A new fusebox.xml parameter "conditionalParse" (which defaults to 'false') controls whether the core files should attempt to determine if the parse file is up to date and avoid regenerating it.  The hedge "attempt to determine" is used because there are certain situations regarding complex plugins and lexicon extensions where the core files will consider the parse file up to date, when it actually isn't.  For most situations, however, conditional parsing can be enabled with no adverse effects.

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.cfm" 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 and for an application.cfm, 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.cfm" is located), and its complement application.fusebox.WebRootToCorePath.

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. You can toggle assertions in fusebox.xml via "useAssertions" (by default, it's TRUE). Parsed fuseactions result in a parsed file with assertions and another without. The corefiles will use the asserted parsed file if it exists and assertions are on, else it will use the unasserted parsed file.  

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. If <cfdirectory> is turned off on your server, this won't work and will produce the same error as in FB4.0 of the given directory not existing.

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. For example "fusebox.undefinedFuseaction.cfm".  If the error template does not exist, then Fusebox will throw the error normally, as in FB4.0.  Error templates will be called with a best-match algorithm, similar to CFCATCH.
A list of possible fusebox core file errors types is below:

Custom Error                 can be thrown from core file:
------------                 ----------------------------
fusebox.missingCoreFile                 runtime
fusebox.versionMismatchException		loader,parser,transformer
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
fusebox.badGrammar.noInvokeeException				parser
fusebox.badGrammar.unregisteredLexiconException		parser
fusebox.badGrammar.missingImplementationException	parser
	

-----------------------------
Fusebox 4.2  changelog
-----------------------------

2004-11-03:
====
IMPLEMENTED - added a fb_.verbInfo struct that contains information useful to custom lexicon verbs.  Like the myFusebox struct, it contains data relevant to the current custom lexicon verb, but is only available during parsing, it is not available during request execution.

IMPLEMENTED - changed the parser to use a series of UDFs (defined at the top of the parser file) for building up the parse file.  Custom lexicon verb implementations can call these UDFs rather than directly appending to fb_.parsedFile as in previous versions.

2004-09-08:
====
IMPLEMENTED - *EXPERIMENTAL* 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. Note: THIS IS NOT OFFICIALLY PART OF FB4.1 ! WE ARE INCLUDING THIS AS A POSSIBLE FEATURE OF A FUTURE RELEASE OF FUSEBOX, NUT NOT GUARANTEED! This way people can explore its usefulness and give feed back over the next 6-12 months and help us decide if it is a good idea with merit or a terrible idea that just sounded "neat". We suspect the former since we've been using it internally for several months already.
