> My options, as I see it are
> 1) using XFB for the indivdual apps and standard for calling those
> apps which would keep things more modular.
> 2) use standard FB for everything.
> 3) use XFB for everything.
I vote for option #1. the Circuits.cfm solution was designed as a way to
include directly related sub-fuseboxes, not as an alternative to Spectra :)
And certainly as a way to avoid having to re-write essentially the same
code. The analogy, I think, is that as easily as you can drop in a custom
tag and begin using it, you could take another FB and 'drop it in" to your
code. But from what you describe, I don't see any upside to having the
entire site be XFB'ed, at least in the way you've said.
It sounds like you'd have a series of applications, some more related to
each other than others, tied together by a common high-level navigational
system and login/logout. If that is right, then it seems like the majority
of the master top-level fusebox would be pure outright <A HREF>'s to the
individual fuseboxes of the apps rather than inlcudes or even XFB links.
Also, another thing about CFB and Circuits is that the code to be included
doesn't all have to be in the same place--just because you're reusing the
shopping cart code doesn't mean it does or does not have to be in only one
spot and then all fuseboxes using it having to circuits.cfm it from one
spot -- you can of course just drop the code beneath any fusebox that needs
it as long as you realize that you then introduce maintainability issues.
Sometimes you just want the overall code, like a shopping cart, that is
already just *done* and then you personalize for that fusebox anyway,
hopefully in a significant enough way to have justified having it in
different locations. Your own case will determine whether this trade-off is
something you can live with.
you know, one thing you can consider, is that even though you may not XFB
the entire site, directly, you can do it indirectly. This is equivalent to
#1, without the huge top-level circuits.cfm file. Example: App A may XFB
App B via a Circuits.cfm. But App B may XFB App C. So even though you don't
explicitly map app C into app A's Circuits.cfm, it can be available just by
virtue of A's going to B which *does* have access to C. So calls to C are
still only done through B. However to do this, you would have to modify the
XFB Circuits.cfm technique that Hal originally suggested (which calls for
explicit inclusion) and instead use one of the other techniques recently
discussed wherein the circuits were programmatically inherited. If you tweak
it a bit you will end up with not inheriting all sub-circuits.cfm without
automatically but inheriting not only the sub-fusebox's index.cfm but also
its circuits.cfm for that one fuseaction.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
