Comment on page
Wheels allows you to create layouts so that you don't need to header and footer code on every single view template.
As a red-blooded CFML developer, you're used to creating include files like
footer.cfm, and then using
<cfinclude>on every single page to include them. The popular way to do it looks something like this:
<p>Some page content</p>
Does that mean that you should
<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.
Layouts to the rescue!
In your Wheels installation, layout files are stored either directly in the root of the
viewsfolder 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.
Let's say that you want to define one layout to be used by every view in your application. You would accomplish this by editing the default layout. The default layout is the
views/layout.cfmfile. In a fresh install of Wheels, you'll notice that it only contains a few lines of code:
The call to includeContent()Simple Example represents the output of your page generated by your view files. Whatever code you put before this snippet will be run before the view. Similarly, whatever code you put after the snippet will be run afterward
For most purposes, this means that you could write code for your page header before the snippet, and write code for the footer after. Here is a simple example of wrapping your view's content with a header and footer.
<li>#linkTo(text="About Us", route="about")#</li>
<li>#linkTo(text="Contact Us", route="contact")#</li>
As you can see, we just wrote code that wraps every view's content with the layout. Pretty cool, huh?
Just like views in Wheels, any variable declared by your application's controller can be used within your layouts. In addition to that, any variables that you set in view templates are accessible to the layouts as well.
Notice in the above code example that there is a variable called
titlebeing 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
To help document this, you can use
<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.
Here's an example:
<!--- Title is required --->
<cfparam name="title" type="string">
<!--- View's Content --->
One layout file that is already created for you is
views/layout.cfm. Think of it as the default layout to be used by any given controller.
If you're writing code for a controller called
pressand there is no layout created for
press, Wheels will automatically use
views/layout.cfmas the layout.
If you implement a layout for the
presscontroller, then that layout will be used instead of the default layout.
So, how exactly do you implement a layout meant specifically for just one controller? Well, that's next...
Let's pretend that you want to create a layout to be used only in a controller called
blog. To do this, you would simply create the layout and save it as
As you can see, the convention is to place your layout file together with the other view files for the controller.
However, if you need to override the name of the layout file or its location in the folder structure, you can specify what layout file to use with the usesLayout() function in the controller's init function instead.
With that code placed in the
controllers/Blog.cfcfile, all actions will now wrap their contents with the
bloglayoutone.cfmfile instead of the
That code tells Wheels to apply the
blogLayoutOnelayout for any actions in this controller except for the
homeaction. In the case of the
homeaction, it will fall back to the default behavior (i.e. using the
If for some reason you do not want the default behavior to be used when conditions aren't met, you can set the
usesLayout(name="blogLayoutOne", except="home", useDefault=false);
You can even instruct Wheels to run a specific function that will determine the layout handling.
It's worth repeating here that everything inside the controller's
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
resolveLayoutfunction on each incoming request.
As you may already know, Wheels's renderView() function is the last thing called in your actions. This function is run automatically by Wheels, so most of the time, you won't need to call it explicitly in your code.
Take a look at this example action, called display:
This assumes that you want for your action to use the layout stored at
The default behavior for the
layoutargument is to look for the file in the current controller's view folder, so here we're still assuming that the
displayaction is in the
.cfmextension will also be added automatically by Wheels, so you don't need to specifically include that part.
If you want Wheels to locate the file in a different folder, you can start the
layoutargument with a forward slash,
/. By doing this, Wheels will know you want to start the search in the root of the
viewsfolder. 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:
You can also create a separate layout that only contains the call to the includeContent() function in it and reference it as described above in Using a Different Layout. This may end up a little ugly though if you start getting a lot of small identical files like this, but the option is there for you at least.
Like many templating languages, Wheels offers the ability to create layout files that can be "inherited" by other layout files. The end goal is to create a "parent" layout that has missing sections intended to be filled in by "child" layouts.
The point I'm trying to make here is that we can use this same functionality to set any type of content for, as an example, sections in our layout files. So, armed with this new knowledge, let's create some nested layout awesomeness.
Say we have a global layout and want to fill out content in it from controller specific layouts, here's how we can do it.
The child layout:
contentFor(pageTitle="My custom title");
Note: If your parent file is one of the default ones named
layout.cfmyou can actually remove the "layout" string above since the default for includeLayout() is
layoutanyway. 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.
The parent layout:
That was a fairly basic example of how you can achieve nested layouts in Wheels to DRY up your code. You can of course expand on this by having entire sections of HTML (like a sub menu for example) be created by the child layouts. Also, as a reminder, don't forget that you can use includePartial() from inside your layout files as well to further keep things DRY.