Dec 23, 2015
Table of contents:
Last week we looked at creating Controllers in Ruby on Rails (Creating Controllers in Ruby on Rails. The Controller is responsible for accepting requests and returning responses.
The final component of the MVC paradigm is the View. The View layer is responsible for generating the HTML response for the request.
In today’s tutorial we will be looking at creating views in Ruby on Rails.
Ruby on Rails is built upon the principles of the MVC paradigm. This makes it really easy to create an MVC application.
By convention, Rails will automatically route Controller methods to specifically named Views.
For example, add the following route to your
get 'articles', to: 'articles#index', as: :articles
Next add the following Controller:
class ArticlesController < ApplicationController def index; end end
Notice we aren’t calling the View in the
Now if you fire up your Rails application and visit
/articles in the browser you should see Rails complaining that the View file does not exist.
Given this scenario, Rails will expect that there should be a View file under
If you add that file and then refresh the application you should see the page is displayed correctly.
As with all of the other conventions of Ruby on Rails, this is designed to make your life easier, but it can be handy to understand the conventions so you know what is going on under the hood.
As you can see from the example above, we don’t need to explicitly render the View because Rails will assume that’s what we want to do.
But sometimes you will need to tell Rails to render a different View.
For example, when you are updating a record, but the user has caused a validation error, you need to send the user back to the edit form so they can correct their mistake:
def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to(@article) else render :edit end end
In the example above, when the
update method returns false I’m calling the
render method with a symbol of
:edit (What are Symbols in Ruby?). This will cause the
edit.html.erb template to be rendered.
If you look under the
layouts directory, under the
views directory, you should find a file called
This is the default layout file that will be used to render the responses.
When choosing the layout to render, Rails will first look to see if there is a Controller specific layout.
For example, if we wanted to display a different layout for the
ArticlesController methods, we could create a
articles.html.erb file under the
You can also specify the layout you want to use in the Controller:
class ArticlesController < ApplicationController layout 'content' end
As you can see from the default
application.html.erb file, there is the following tag:
<%= yield %>
yield tag is where the content from the View will be injected.
In the default example, the
application.html.erb file contains the header and the footer of the website, and the content is then injected into this template via the call to
You can also have multiple
yield areas in a layout, for example:
<div class="main"><%= yield %></div> <div class="sidebar"><%= yield :sidebar %></div>
Here we’ve got the default
yield, but also a named
Now in your View file you can specify the content for the sidebar:
<% content_for :sidebar do %> <p>I'm in the sidebar</p> <% end %> <p>Hello, World!</p>
A good practice when building up the View layout of a web application is to extract components into Partials.
This makes it easy to deal with certain aspects of the design in isolation, and makes it easier to use the same components in multiple places throughout the application.
Here’s how you render a partial:
<%= render "sidebar" %>
This will render the file
_sidebar.html.erb. By default partials should be named with a preceding underscore to show that they are partials. However, you don’t need to use the underscore in the name when rendering a partial.
By default Rails will use
erb templates so you can use Ruby inside of your Views.
However, there are a couple of alternatives that might be worth considering.
Probably the most well known is Haml, and another alternative is Slim.
Both Haml and Slim are abstractions that allow you to write cleaner and clearer markup. This markup is then rendered into HTML.
For a long time I was against using an abstraction for HTML, but to be honest, I find HTML really ugly and overwhelming, so I tend to use Slim as my abstraction of choice.
You don’t have to use an abstraction like Haml or Slim if you are happy with ERB templates, but it might be worth looking into.