See .. it's the overhead I don't get. I'm developing a site that's nested a
few layers deep. All I do to accomplish this smoothly is this:
Every circuit has it's own app_globals
Each app_globals includes the app_globals from the circuit directly above
them.
The index.cfm in each circuit controls the flow as normal.
I now have an app that's nested 4 circuits deep with no problems. Every
circuit can stand on its own or be used in any application. The only files
that might need to be changed are the app_locals and maybe the app_globals
if a circuit becomes the root.
I don't see why it needs to be any more complicated than that?
Todd Ashworth --
----- Original Message -----
From: "Nat Papovich" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Tuesday, March 27, 2001 2:59 PM
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
