Tally List : mailing list management, archiving, and analysis
click for archive home
 
Archive of:
Fusebox
Cold Fusion Fuse Box List
 
home
24 hour view
quick stats
weekly updates
 
all tallylists
corporate solutions
archive your favorite
help / feedback


Search the Tallylist search by keyword:

About CF Fusebox Methods :
product's home
product's list home
 
  Archived TallyList / Fusebox: 
Subject: Re: Extended Fusebox
John Quarto-vonTivadar (63p/+0r)     Posted: Thursday 10 May 2001
This post: 52 views, +0 rating

> 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


Similar Subject Line Posts (+/- two weeks of this post)
Re: Extended Fusebox  11 May 2001   (48 v/ +0 r)
Re: Extended Fusebox  10 May 2001   (63 v/ +0 r)
Re: Extended Fusebox  10 May 2001 (this post)   (52 v/ +0 r)
Extended Fusebox  10 May 2001   (44 v/ +0 r)
 

Send a reply to the Fusebox list!
click to send a reply! NOTE: Many lists will reject your post unless you have already registered with them. Also - don't forget the right account to send from (for those with multiple emails!)

Feedback: If this post was exceptionally helpful, please help by giving this post a positive review.

 

TallyList : copyright Ububik - 2000