copy of the beta core files from http://beta.fusebox.org.
Have fun.
sim
----- Original Message -----
From: Sandy Clark <[EMAIL PROTECTED]>
Date: Mon, 20 Sep 2004 16:38:41 -0400
Subject: RE: FB4.1 ETA?
To: CF-Talk <[EMAIL PROTECTED]>
I'm one of the few that has it. (Team Fusebox!) Noted here for you viewing
pleasure is the readme that details the changes.
-----------------
Fusebox 4.1 changelog
-----------------------------
v 4.1.0:
====
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 is the relative
path from the web root (where index.cfm is) to the location of the root 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-conditional reloading of XML in development mode. During
development mode, the core files will determine if the fusebox.xml and
circuit.xml files need to be reloaded for the current request, and only
reload them if needed.
IMPLEMENTED-optional conditional regeneration of the parse file, applicable
only in development mode. A new fusebox.xml parameter "conditionalParse"
(which defaults to 'false', to mimic Fusebox 4.0 behavior) 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. If your plugins and lexicons are
stable since the last parsing then you should encounter no problems with a
TRUE. When in doubt during that key in-between time, prefer TRUE which will
fully parse on each request as in FuseBox4.0
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-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.
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.
Example: "fusebox.undefinedFuseaction.cfm" 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
Sandy Clark
http://www.shayna.com <http://www.shayna.com/>
CF Pretty Accessible at http://www.shayna.com/blog
Now offering 4 days Hands on CSS training October 11-14th. Rockville, MD.
For more information go to:
http://www.teratech.com/training/oc_classes.cfm#css
_____
From: Nathan Strutz [mailto:[EMAIL PROTECTED]
Sent: Monday, September 20, 2004 3:26 PM
To: CF-Talk
Subject: Re: FB4.1 ETA?
Tangorre, Michael wrote:
> > From: Damien McKenna [mailto:[EMAIL PROTECTED]
> > Does anyone have an ETA on the release of Fusebox 4.1?
>
> Supposedly sometime this week according to the people I talked to at the
> conference this past weekend. I can't wait. I thought maybe they would
> have given it to us at the conference... They like to watch us drool :-)
>
Any word on what's new in 4.1? I'm very interested, though I'm not a
full-fledged fuseboxer.
-nathan strutz
http://www.dopefly.com/
_____________________________________
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
