> I have used a slightly different version of this in the past. What I
> wanted to know was why in the examples available on Fusebox.org(Fusebox
> 101), the cf_bodycontent has been removed from the 'top' level fusebox.
at the time, the author did not use cf_bodycontent since he does little
actual HTML work. There is nothing inconsistent with the use of
cf_bodycontent with XFB.
what you do is one of two things:
1) wrap it around the <CFIF> that includes the index.cfm CFSWITCH. If so the
files defined for bodycontent will be used no matter which circuit is called
(I prefer this method)
2) wrap it around the index.cfm's CFSWITCH statement, which is the
'traditional' way. If you do this then you'll cause a potential
reverse-inheritance that any sub-circuit will only encounter cf_bodycontent
as part of its own index.cfm rather than the top-level's index.cfm. This
may cause a error (sometimes two bodycontent encased within each other), or
it may work fine (if you define the header/footer files in the
myGlobals.cfm), or it may cause unexpected results (another set of
header/footer files may be used). And it may do all three depending on the
code in that sub-circuit. Either way you'd then have to step through all
that sub-circuit's code to find the problem, which is the antithesis of what
XFB is striving for. So, try to talk yourself into #1 above.
also, of course, remember to close with </cf_bodycontent> and to also
CFINCLUDE app_layout.cfm. Get the versions of both those tags that treat
attributes.headerfile, attributes.footerfile as lists which expands the
functionality tremendously.
two suggested solutions: one way, follow #1 above, and in root level
index.cfm or myGlobals.cfm define the headerfile/footerfile. If any of your
subcircuits need "extra" navigation then in their index.cfm (remember their
own myGlobals.cfm won't fire) then ListAppend them to the headerfile
variable (or ListPrepend them to the footerfile).
Another way to do it is to call a switch in the root index.cfm which
modifies the headerfile variable right there depending on the value of the
circuit in the "circuit-dot-fuseaction" fully qualified fuseaction. This may
work especially well if you use Lee's CF_XFB tag. I've done it both ways
with equal success, although I prefer the latter. If your sub-cuit has some
sort of navigational stuff that must be included no matter what regardless
of graphics and stylesheet and not to have it would break the subcircuit,
then you might end up choosing the former.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
