header.cfm
and footer.cfm
, and then using <cfinclude>
on every single page to include them. The popular way to do it looks something like this:<cfinclude>
your headers and footers in every view in your Wheels app? Heck no! If the structure of your pages ever changed, you would need to edit every single page on your site to make the fix.views
folder or contained in one of the controllers' view folders. Let's go over how layouts work, starting with the simplest way and then moving on to more complex setups.views/layout.cfm
file. In a fresh install of Wheels, you'll notice that it only contains a few lines of code:title
being output in between the <title>
tags. This would require that any controller or view using this particular layout would need to set a variable named title
.<cfparam>
tags at the top of your layout files. That way any developer using your layout in the future could easily see which variables need to be set by the controller.views/layout.cfm
. Think of it as the default layout to be used by any given controller.press
and there is no layout created for press
, Wheels will automatically use views/layout.cfm
as the layout.press
controller, then that layout will be used instead of the default layout.blog
. To do this, you would simply create the layout and save it as views/blog/layout.cfm
.controllers/Blog.cfc
file, all actions will now wrap their contents with the bloglayoutone.cfm
file instead of the layout.cfm
file.except, only
, and useDefault
arguments for further customization.blogLayoutOne
layout for any actions in this controller except for the home
action. In the case of the home
action, it will fall back to the default behavior (i.e. using the views/blog/layout.cfm
file).useDefault
argument to false
.config()
function runs only once per application and controller. This is why you can't perform the logic that decides which layout to use directly inside the config()
function itself. Instead, you tell Wheels to always run the resolveLayout
function on each incoming request.views/blog/visitorlayout.cfm
.layout
argument is to look for the file in the current controller's view folder, so here we're still assuming that the display
action is in the blog
controller. The .cfm
extension will also be added automatically by Wheels, so you don't need to specifically include that part.layout
argument with a forward slash, /
. By doing this, Wheels will know you want to start the search in the root of the views
folder. Let's say that you're storing all miscellaneous layouts in its own folder, simply called layouts
. You would display one of them with the following code:layout
argument on renderView() will override any settings you may have made with the usesLayout() function. This gives you finer-grained control.name
argument. The reason we don't have to use it above is because it defaults to body
. This body
variable has been set internally in the Wheels framework code with the use of the contentFor() function.layout.cfm
you can actually remove the "layout" string above since the default for includeLayout() is layout
anyway. We're just including it here for completeness and to show that you can of course achieve this regardless of what your parent layout file is named.body
" because that is the default on the includeContent() function.