Oh that. Yeah Gabe came up with that when he developed the technique of
using an app_model.cfm to define a javascript like DOM using request scoped
variables at the beginning of the application. Except I believe the
original used a 1 dimensional array. The code your referring to below was
used in the Jazloft code.
Fred
----- Original Message -----
From: "John Quarto-vonTivadar" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Monday, May 14, 2001 12:40 PM
Subject: Re: A few more Questions (was RE: Calling Fuses without Layout)
> Lee and Alan asked:
>
> > Yeah, is there really a CF_BodyContent that uses lists? Sounds
> interesting,
> > but I'm not really sure on what it would do.
>
> technically, it's the app_layout.cfm where the lists are manifested, here
is
> a section of the code:
>
> <cfif len(request.page.headerfile)>
> <cfloop list="#request.page.headerfile#" index="listelement">
> <cfinclude template="#listelement#">
> </cfloop>
> </cfif>
>
> ditto on the footer. Anyway, just take a gander at the app_layout.cfm to
see
> what I mean. However, the point of using this is when emplying
> CF_BODYCONTENT where the values for the headerfile and footerfile are set
..
> So, instead of defining them with CFSET and CFPARAM you also have the
option
> of defining them with ListAppend (for headerfiles) and ListPrepend (for
> footerfiles).
>
> here's a quick example (you can extend this afterwards to the Circuits by
> analogy):
> let's say I have a bookstore site and have some "Home" level stuff I want
> to wrap around the site. Myabe some overall layout (META tags, a
stylesheet,
> maybe wrap some top graphics inside tables etc) and some static links like
> About Us and that sort of thing--it would also have some links to dynamic
> fuseactions perhaps like "Find a Book". It has a headerfile of
> header_home.cfm and footer_home.cfm. As these exist all thru the site, I
> probalby have them in myGlobals.cfm as <cfset
> attributes.headerfile="header_home.cfm"> etc.
> Now suppose that when I click "Find a Book" I also want to load some
> additional graphics right at the end of the header file (ie more
> navigational graphics typically) and these might be linked images for
> "search our site" "search our affiliates" "search amazon.com" . Anyway you
> get the point, what I'm trying to do is to say that in some cases (here,
"in
> some exitfuseactions") the headerfile/footerfile may actually have more to
> it than in the default case. How do I handle this with CF_Bodycontent?
>
> well you've got three choices:
>
> 1) you can have multiple single header/footer files. in the case above,
you
> may have header_home.cfm and header_find.cfm and header_find.cfm has
> virtually all the same code as header_home.cfm except for those <IMG>s
> 2) you can have a single larger file that defines the contents with some
> CFIF's or with a CFSWITCH (the home stuff loads and then does a CFIF to
> possibly include some more stuff or to CFINCLUDE another file just for
that
> CFIF )
> 3) you can use CF_BODYCONTENT's ability to process lists of files
>
> of course we're talking about case 3 here. Cases (1) and (2) work just as
> well, it really depends on how "deep" this will all have to go in the end.
> Using method 1, when fuseactions that need that extra layout are called
you
> might do:
> <cfcase value="findbook">
> <cfset attributes.headerfile = "header_find.cfm">
> <cfset XFA.searchbook = "home.searchbook">
> <cfinclude template="dspSearchBook.cfm">
> </cfcase>
>
> so you're replacing the default header with a custom header. In a pinch
and
> when it happens infrequently this is a quick way to handle it. (I use this
> especially when i do NOT want the standard header, for exmaple in a
> small-pop window where I might only want to load a stylesheet so as to
have
> its contents look similar to the main site but without all the branding
> logo's and the like---or when doing a link to a PDF file where I must be
> sure not to load any HTML at all before the PDF file header, etc. You get
> the point, I'm sure). Method 2 is just a variant of this wher einstead you
> put the logic into the headerfile rather than the fuseaction
>
> Using method 3, then when the fuseactions that need that extra layout are
> called you do
> <cfcase value="findbook">
> <cfset attributes.headerfile =
> ListAppend(attributes.headerfile,"header_find.cfm")>
> <cfset XFA.searchbook = "home.searchbook">
> <cfinclude template="dspSearchBook.cfm">
> </cfcase>
> where now header_find.cfm consists of nothing more than the "extra" stuff
> that needs to be added (it doesn't include the same stuff as
header_home.cfm
> since it's already there).
>
> when CF_BODYCONTENT is done and proceeds to app_layout.cfm it will process
> through attributes.headerfile which consists of a list of
> "header_home.cfm,header_find.cfm" and both file will get prepended to the
> page output, in order. Note that in this case I probably did not have
> anything "extra" to add to the footerfile so attributes.footerfile
consisted
> only of "footer_home.cfm"....if I had had something extra to put in the
> footerfile I'd've handled it also in the CFCASE as <cfset
> attributes.footerfile = ListPrepend(attributes.footerfile,
> "footer_find.cfm")> where I have to Prepend rather than Append so that
when
> the onion gets unwrapped it unwraps the special footer for the Find
*before*
> the regular footer for the Home.
>
> Again, if you're doing this only in one or two spots then perhaps Methods
> (1) and (2) are better suited to your needs. I use #1 all the time. But
once
> in a while in a fairly complex setting, particularly Admin backends when I
> want to perhaps so something like having a tab interface for the Admin
site
> and have the color of the tab change depending on which one I've clicked
and
> also have some special sub-navigation show up depending on the tab picked,
> if you have more than a few tabs you end up using a big-ass CFIF as part
of
> the single headerfile.cfm . If instead you take advantage of list nature
of
> the attributes.headerfile, you can easily add and modify the
> sub-navigational elements very very fast, without having to spend much
time
> re-thinking any of the "logic" in the headerfile ("now let's see this
table
> is nested 3 deep so that the logo could get in just the right spot and so
> now I 've got to add a colspan=17 in order to..." oh! that drives me
nuts!
> and I invariably goof something up if I touch someone else's code 6 months
> later)
>
> does that make any sense? It's good to know that this method is available.
> And if things get complex and you've got a bunch of CFIF's then using this
> technique might actually be faster since there is little conditional logic
> when it's used.
>
> [Please note that if you use Circuits.cfm you will also have to pass along
> to the CF_BODYCONTENT the relative path to any of the header/footer files
> when setting a value for attributes.headerfile/footerfile. But you have to
> do that anyway even if the list is single-valued.]
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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