I use the same technique and I'll tell you that XFB is really no different,
just takes a different approach. If you (at a low end circuit) traverse up
each directory structure using say app_locals (cfinclude ../app_locals.cfm)
you eventually get to the root, load things like app_server and app_login,
etc. then each call from every circuit returns from its call to its parent,
getting you back to the circuit where you started, then you move on from the
call to app_locals into any configuration necessary for that circuit to
work, then start checking your fuseactions.
XFB is no different in the respect that it will also traverse your directory
structure, load appropriate information as it works its way down to the
target circuit, then on to the fuseaction. I have now done it both ways
with nests as deep as six (don't ask) and everything works fine either way.
XFB just adds a few interesting mechanisms to help traverse the nests.
-----Original Message-----
From: Todd Ashworth [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2001 4:22 PM
To: Fusebox
Subject: Re: Musings on Attributes (was Best Practices...) - in summary
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
