Yahoo! I completely concur with Mr. Papovich. That was the clearest
statement of my position I've heard: If XFB works for you, great; if not,
that's great too. I'm not trying to split the Fusebox community or make
anyone feel that they're missing the boat if they use Fusebox without
nesting, XFAs, Fusedocs, etc. There's much love in the Fusebox world and I
just wanna be a part of it.
Oh, and I *especially* agree with the part about being a CF genius. ;-)
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2001 3:00 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...) - in summary
About this whole complexity of XFB thing...
There definately is more overhead involved in using XFB above regular FB.
By-the-book FB requires the use of a few files, all which are easily
understood, easily drawn on a whiteboard, and you create yourself. The only
tag that is somewhat required is the formurl2attribs tag, but it isn't even
needed for complete Fuseboxness (and consequently, this tag can prove
valuable in developing non-Fusebox apps).
Hal makes the point that the extra complexity never needs to be examined. It
is the "engine under the hood". His style of nesting adds another
"generation" (if you will) to Fusebox. Similar to how ColdFusion is built on
C, which is built on assembler, which is built on 1's and 0's, XFB is built
on Fusebox, which is built on ColdFusion, which is built on... (and on)
What this means is that developers are one step removed from the intricacies
of the behind-the-scenes stuff. This may make you feel like someone is
trying to hoodwink you, or that you're relying too heavily on an awkwardly
built house of cards, hoping that is stays together. This is not the case.
By adopting the nesting portion of Extended Fusebox, you can remove yourself
from the tediousness of the 1's and 0's, and instead rely on a proven
abstraction, created by a CF genius. In the same way regular Fusebox allowed
developers to focus not on the application's architecture but getting the
problem solved quickly, Extended Fusebox allows developers to focus on
getting the problem solved more quickly, by extending on Fusebox's
fundamentals.
If you don't want to adopt XFB - don't. If you do want to adopt XFB, read
the whitepaper, do Hal's free 100+ slide tutorial on his site, and dive in.
Look under the hood if you want to - that's what I did first thing, to
rewrite circuits.cfm, nesting.cfm and reorganize stuff. Hal is not selling
his methodology (although he could ala iiFramework), so you can adapt it for
your personal style. If you're not ready to learn something new, start
small - pick up Exit Fuseactions first.
Now if you're pining for one of Hal's classes, but the cost is throwing your
boss or your morals for a loop, take a moment to justify it. Even at $5000,
it would take a developer only a few months to make up for the cost of the
class. If you're happy with your current methodology style, and don't want
to pay for something new, that's fine too. By-the-book Fusebox will continue
to exist for quite some time.
NAT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
