There are probably a number of alternatives, but I'm generally inclined to
go with the simple solution: use cfincludes and nested directories. (You've
probably already thought of this).
index.cfm
<cfinclude template="header.cfm">
... body content ...
<cfinclude template="footer.cfm">
So then the header and footer templates themselves have their own includes:
header.cfm
<cfinclude template="../header.cfm">
...sub-header menus, etc. here ...
footer.cfm
... sub-footer stuff here ...
<cfinclude template="../footer.cfm">
If you want to put all your headers in the same folder (or tree), you could
get even more creative:
index.cfm
<cfparam name="attributes.skin" type="string" default="">
<cfinclude template="layout/#variables.skin#_header.cfm">
... body content here ...
<cfinclude template="layout/#variables.skin#_footer.cfm">
If you wanted a sub-section this way, any given header or footer file could
include any other header or footer file above or below its own layout info.
My CMS has its own system for handling layouts as a single piece, but it's
all data driven, so it's pretty useless outside of its own context.
Personally I think that unless you're using a data driven cms-style layout
system, the individual includes are better anyway, since using
<cfsavecontent> (or the equivalent custom tag) makes it impossible for you
to use <cfflush> within the content area on the same page.
On MX I suppose you could use CFC's for data driven layouts...
<cfoutput>#layoutCFC.showHeader(layoutname)#</cfoutput>
... body content here ...
<cfoutput>#layoutCFC.showFooter(layoutname)#</cfoutput>
Or for that matter just a UDF:
<cfoutput>#request.getLayout("head",layoutname)#</cfoutput>
... body content here ...
<cfoutput>#request.getLayout("foot",layoutname)#</cfoutput>
And that would eliminate the need to reference a file path in your document
-- the udf or CFC could handle any relative path fetching -- as a matter of
fact, there's a getRelative() function in my open-source API for the purpose
of fetching a relative path from the current template given an absolute file
path. It's just like expandpath() accept more useful, since expandpath works
from the base template path only and relative paths for includes _must_ be
from the current template. :)
Actually this (the UDF) could work on CF 5 also...
<cfmodule template="#request.getLayout(layoutname)#" layoutmode="head">
... body content here ...
<cfmodule template="#request.getLayout(layoutname)#" layoutmode="foot">
This way you would put all the layout code (header and footer) in the same
template (always a plus) and you would use the attributes.layoutmode
variable to determine which portion of the layout to display.
<cfswitch expression="#attributes.layoutmode#">
<cfcase value="head">
<cfinclude template="parentlayout.cfm">
... menu content here ...
</cfcase>
<cfcase value="foot">
... footer content here ...
<cfinclude template="parentlayout.cfm">
</cfcase>
</cfswitch>
You don't have to call the parent layout as a custom tag because it will use
all the attributes from the last child layout. If you want to make sure that
the layouts templates get all the attributes variables, you can do that by
specifying attributecollection="#attributes#" right next to
layoutmode="head|foot" -- the tag will get the hard-coded layoutmode
attribute injected into the rest of the attributes. :)
Anyway... I hope I've given you some inspiring ideas. :)
p.s. It seems that I'll likely be in Dallas soon. :)
Looking forward to the CFUG meetings.
s. isaac dealey 954-776-0046
new epoch http://www.turnkey.to
lead architect, tapestry cms http://products.turnkey.to
tapestry api is opensource http://www.turnkey.to/tapi
certified advanced coldfusion 5 developer
http://www.macromedia.com/v1/handlers/index.cfm?ID=21816
> I've been fuseboxing for a while now and lately I've been
> trying to wean
> myself from it. I'm not real thrilled about the nested
> layouts and
> such, but I can't seem to find a way to duplicate the ease
> of navigation
> that it presents. I've been toying around with ideas
> about how to
> emulate the abstraction of the directory trees. Have you
> found a
> reliable method?
> Thanks.
> Marlon
> S. Isaac Dealey wrote:
>>
>>I don't use FB for my own development -- I use the
>>attributes trick so that
>>I can call certain base templates as custom tags if it'll
>>help, and I use an
>>equivalent of the fuseaction variable and the fbx_switch
>>that's more dynamic
>>(actually just dynamic includes). Speaking of which --
>>apparently a few
>>people have run into problems with migrating FB2/3
>>applications to CF MX as
>>a result of the 64k method limitation of the underlying
>>Java engine.
>>Apparently when MX generates a java class for a new
>>template, it puts
>>everything in a single method, so if you've got a
>>switch-case in the
>>template it'll examine all those includes and include the
>>contents of all
>>those included files in the generated Java code. So even
>>if your switch case
>>statement only has 2 cases like <cfswitch
>>expression="#fusebox.fuseaction#"><cfcase
>>value="a"><cfinclude
>>template="a.cfm"></cfcase><cfcase value="b"><cfinclude
>>template="b"></cfcase></cfswitch> you could still exceed
>>the 64k limit if
>>the CF Server generates more than 64k of combined Java
>>code from a.cfm and
>>b.cfm (i.e. between them, not per file).
>>
>>
>>
>>
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
> Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
