> 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/fusebox@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists