I put the CF_BodyContent directly around the CFSWITCH, ie within the CFELSE clause. If I do this in every circuit, then I ensure that BodyContent is only called once, by the actual "target" circuit. The target circuit also invokes the layout fuse within the CFELSE block, but the location of the layout fuse is inheritable from the home circuit. So you get one call to BodyContent, and one call to the layout fuse.

I can't see any problem putting BodyContent around the entire CFIF block, except that it will be execute once for every level of nesting before you reach the target fuse. That shouldn't cause any errors - it's just some unnecessary work.

Anyway, I am still pondering John's ideas. There's usually a gem or two in there.

Lee.

>From: "John Quarto-vonTivadar" <jcq@mindspring.com> >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