Rails applications are developed using the Model View Controller (MVC) pattern. The easiest way to show how Rails uses MVC is by looking at a simplified example of the Rails request lifecycle as seen in Figure 2.1, “MVC in action: the Rails request lifecycle”.

Figure 2.1. MVC in action: the Rails request lifecycle

Here’s an example user scenario: let’s imagine that your grandmother wants to purchase a book on tribal tattoos on an online store. Let’s break down the steps of visiting the front page of the store in the context of the MVC pattern:

This approach to organizing application components makes for readable and maintainable projects as it’s predictable where each piece of code should go and can be found: Models deal with interactions with the database and business logic (typically the bulk of your application), View templates are where HTML and the like goes, while Controllers are the thin layer coordinating the two. Without this separation of concerns, you end up with SQL in your HTML, caching code all over, and a general mess on your hands, making writing new features an exercise in masochism.

Another pattern that permeates Rails’ design is Representational State Transfer (REST), an architectural idea of how a well-designed web application should behave. It defines a web application as a collection of resources accessed through uniform, predictable URIs and HTTP verbs like GET, PUT, POST, and DELETE, and returning a representation of a resource that transfers the client (a user’s web browser) into a certain state. This approach frees you from having to make architectural decisions about the layout and composition of your application and its API. We’ll see later about how this idea is what lets Active Resource work so well.

# create a record
book_author = Person.create(:name => "Edward", :nationality => "Canadian")

# retrieve records
canadian_authors = Person.where(:nationality => "Canadian")

# update a record
book_author.name = "Edward Ocampo-Gooding"
book_author.save

# delete a record
book_author.destroy

class Person < ActiveRecord::Base
  belongs_to :family
  has_one :free_time_activity
  has_many :interests
end

edward = Person.where(:name => 'Edward Ocampo-Gooding')
edward.interests.create(:name => 'Open Data')

john = Person.where(:nationality => 'American').first

puts john.gray_hairs  # The Person#gray_hairs method appears automatically
john.gray_hairs = 9   # The Person#gray_hairs= method also appears automatically
john.save

class Animal < ActiveRecord::Base
  validates :known_population, :numericality => true
  validates :biological_name, :uniqueness => true, :presence => true
end

<h1>All People</h1>
<ul>
<% Person.all.each do |person| %>
  <li><%= person.name %> is having a birthday 
    in <%= distance_of_time_in_words_to_now(person.birthday) %></li>
<% end %>
</ul>

<h1>All People</h1>
<ul>
  <li>Edward is having a birthday in 11 days</li>
  <li>James is having a birthday in 11 days</li>
  <li>John is having a birthday in 156 days</li>
  <li>Cody is having a birthday in 90 days</li>
</ul>

class PeopleController < ApplicationController
  before_filter :ensure_person_is_authenticated
  
  def index
    @people = Person.all
    
    respond_to do |format|
      format.html # index.html.erb
      format.json  { render :json => @people }
    end
  end

  # ...
  
end

To give you a feel of how quickly and elegantly you can develop web applications with Rails, let’s build a video jukebox.

This application is going to

To keep it simple, we’re going to assume the video is already up on the web somewhere, so its HTML embed code will be used instead of actually storing the video.

If you don’t have Rails installed, see the Appendix for instructions.

Begin by creating a skeleton Rails application:

$ rails new video_jukebox

Take a look at the application’s directory tree and the typical files and configuration needed in every Rails application:

Take a look at what your application looks like by starting up its server:

$ cd video_jukebox
$ rails server
=> Booting WEBrick
=> Rails 3.1.0 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-09-18 02:57:11] INFO  WEBrick 1.3.1
[2011-09-18 02:57:11] INFO  ruby 1.8.7 (2011-06-30) [i686-darwin11.1.0]
[2011-09-18 02:57:11] INFO  WEBrick::HTTPServer#start: pid=61839 port=3000

With the server running in a terminal, visit http://localhost:3000 in a web browser. If everything is working correctly, you should be looking at a web page with some suggestions on how to start writing your application as seen in Figure 2.2, “If you can see this, Rails is correctly installed.”.

Figure 2.2. If you can see this, Rails is correctly installed.

Follow the steps suggested in the browser and start by changing directories into the project and creating a video resource with a title and HTML embed code attributes:

$ rails generate scaffold Video title:string embed_code:text

Running just this one command generates all we need for a working video resource. Let’s take a look at some of the files just created:

The scaffold generator also created a database migration to update the database schema with the new table and fields the video resource will use. Take a look at it in db/migrate/20100131231323_create_videos.rb :

class CreateVideos < ActiveRecord::Migration
  def change
    create_table :videos do |t|
      t.string :title
      t.text :embed_code

      t.timestamps
    end
  end
end

Instead of editing the routes as recommended in step 2 of the “Welcome Aboard!” screen at http://localhost:3000, skip to step 3 and run the migration the scaffold generator created by typing rake db:migrate

The results should look like this:

$ rake db:migrate
==  CreateVideos: migrating ===================================================
-- create_table(:videos)
   -> 0.0022s
==  CreateVideos: migrated (0.0023s) ==========================================

Running the migration creates a SQLite3 database for you in db/development.sqlite3 and creates a table called "videos" with the schema we specified earlier.

Let’s take a deeper look at the CreateVideos migration and at what just happened.

Active Record migrations define a change method that specifies some changes to the schema, or some code to run to put the local database schema into a certain version. By versioning your database schema via these migrations, you gain the same benefits that you get from using a source control system:

The typical thing you’ll be doing is migrating up a version, which is what just happened when you ran rake db:migrate. In this case, it created a new table videos with a column title of type string (usually 255 chars, but the specifics depend on the database being used) and a column embed_code of type text. Timestamp columns created_at and updated_at are also created in the videos table – these column names are special and when detected by Rails, are set accordingly when a model that maps to that table is created or updated.

You can also specify self.up and self.down methods in a migration instead of change to instruct Rails what to do when migrating up or down specifically. Migrations are also great for flexible bulk data inserts, deletes and updates. There’s also a built-in mechanism in Rails for cleanly seeding your database with initial data. Learn more about this sort of stuff in Chapter 4, Active Record.

At this point, we can start playing around with the application. Believe it or not, we’re done with the hard parts of writing this application.

Make sure your application server is up by running

$ rails server

then visit http://localhost:3000/videos to see a page like Figure 2.3, “Rendered output of the VideosController#index action”.

Figure 2.3. Rendered output of the VideosController#index action

Click on the New video link and start playing around with the app to see it working already.

Make sure to watch the URIs in your browser’s location bar and the log messages coming from the terminal you started the application server in, or by tailing tail -f log/development.log – you should be seeing messages like POST "/videos" followed by Processing by VideosController#create as HTML

With that said, let’s finish up this app. A good next step would be to make it so that when you visit http://localhost:3000/, the application routes to the VideosController#index action and you see the same view when you visit http://localhost:3000/videos

Set this up by adding the following under the resources :videos line in config/routes.rb:

root :to => "videos#index"

Next, delete public/index.html:

$ rm public/index.html

After you’ve done that, reload http://localhost:3000 and you should be looking at your videos/index page.

If you’re still looking at the same “Welcome aboard” page, make sure you’ve deleted public/index.html – everybody makes this same mistake.

Curious about how that public/index.html file works and why if you don’t delete it, it’ll always be served up instead of anything you’ve set a default route for? Any path that resolves to a file under public/ will be served up before Rails checks its routes. This is also how pages like http://localhost:3000/404 and http://localhost:3000/500 render without having to depend on a working Rails setup – just take a look at public/404.html and public/500.html.

Let’s add a video via its HTML embed code and have it render correctly.

Visit http://localhost:3000/ and create a new video record. Set its title to “First thing I could think of” and grab the HTML embed code from the first video you see from http://vimeo.com or your favourite online video site. (There should be a button somewhere on the video site that says “embed”.) The embed code should look like this:

<iframe width="425" height="349" src="http://www.youtube.com/embed/QH2-TGUlwu4"
   frameborder="0" allowfullscreen></iframe>

After creating the video, you can see that it was created, but the video embed code isn’t rendering correctly. This is because Rails escapes all dynamically rendered text in views to prevent cross-site scripting (XSS) attacks where some external JavaScript does something nasty to your users.

We want to display this embed code, but don’t want to open up a XSS exploit vector. We can do that by just making sure only a few kinds of HTML tags can be used when we render a video’s embed code, like <iframe> – anything else like a script tag that could contain malicious JavaScript should be HTML-escaped so that it won’t be evaluated by the browser as executable code.

This functionality is built-into Rails in the form of Action View’s sanitize helper – it lets you specify certain HTML elements and attributes to pass through and disables escaping on the rendered output.

Open up and edit the view used to render single videos, also known as the video show page: app/views/videos/show.html.erb

Change

<p>
  <b>Embed code:</b>
  <%= @video.embed_code %>
</p>

to

<p>
  <b>Embed code:</b>
  <%= sanitize @video.embed_code, :tags => ['iframe'] %>
</p>

Refresh the video show page you’re looking at (e.g., http://localhost:3000/videos/1), to see your app safely rendering the video embed code like in Figure 2.4, “Baked-in XSS protection thanks to data-sanitization by default is nifty”.

Figure 2.4. Baked-in XSS protection thanks to data-sanitization by default is nifty

Nice work! It looks like this application is almost done. Before we move on to validation, comments, RSS, and AJAX, let’s poke around our application to make sure everything is working correctly.

Try visiting videos/index at http://localhost:3000/

Hmmm… it looks like the video isn’t rendering correctly. Open the view used to render this URI (app/views/videos/index.html.erb) and look at this line:

<td><%= video.embed_code %></td>

While it would be easy to just change it to the sanitized version we used earlier, having to use the same view code in two places doesn’t feel right. If we realized some element in the sanitization call was missing, we might forget to change it in both places and cause a bug to slip in. We need to encapsulate the video embed code sanitization.

This sort of functionality fits nicely in a helper: a method used in views to encapsulate complex logic and clarify what’s happening in the view. Open up app/helpers/videos_helper.rb and change it to look like this:

module VideosHelper
  def sanitize_embed_code(video)
    sanitize video.embed_code, :tags => ['iframe']
  end
end

Now we can use it in both app/views/videos/show.html.erb and in app/views/videos/index.html.erb

Change app/views/videos/show.html.erb to look like this:

<p>
  <b>Embed code:</b>
  <%= sanitize @video.embed_code, :tags => ['iframe'] %>
</p>

and app/views/videos/index.html.erb to look like this:

<p>
  <b>Embed code:</b>
  <%= sanitize_embed_code @video %>
</p>

Refresh your browser and make sure everything is working. If you’ve got a bug, look at the end of the application log in log/development.log for clues, or tail -f it as you run it.

While playing with submitting videos, you might have noticed that it’s possible to create a video without a title or embed code. That’s not good. We need some validation to prevent creating video entries in the database with missing titles and/or embed code.

The good news is that Active Record models come with all sorts of validation code to handle common situations like this one. In fact, we can handle this requirement by adding just this one line to the top of the Video model in app/models/video.rb:

class Video < ActiveRecord::Base
  validates :title, :embed_code, :presence => true
end

Try submitting a video without a title or embed code and you can see the validation we just added in action, showing an error message and a red outline around the missing elements that need to be fixed. Not bad for just a single line of validation!

We should also validate the embed code. For now, let’s just check that the code contains the beginning of an embed tag.

Change the Video model in app/models/video.rb so that it looks like this:

class Video < ActiveRecord::Base
  validates :title, :embed_code, :presence => true
  validate :must_have_valid_embed_code
  
  def must_have_valid_embed_code
    unless embed_code.include?("<iframe")
      errors.add(:embed_code, "Must include an iframe tag")
    end
  end
end

The validate method takes the name of an instance method and runs it during validation, making it really easy to write custom validation. In this case, the method must_have_valid_embed_code adds an error to the instance of the model on the embed_code attribute with a message about it needing to include an embed tag.

Try creating a new video with obviously invalid embed code with this custom validation in place and see what happens.

Rails also comes with other common validators like length_of, numericality, format which ensures some text follows a certain format or pattern like an email or phone number field, confirmation for when you want a password to be entered twice, and acceptance for when you need a terms of service to be accepted. Find out more about validations in Chapter 4, Active Record.

We’re almost done writing our application. The next step is to open up the videos resource to RSS readers.

An RSS reader is just like a regular web browser, except instead of asking for HTML, it asks for a special blend of XML called Atom. So in order to support RSS readers asking for videos, we just need to modify the VideoController to respond to requests for the RSS format and content-type.

Fortunately for us, this is easy to do in Rails. In fact, your application already supports asking for JSON representations of resources like videos/index.

Give it a shot by visiting http://localhost:3000/videos.json and looking at the source. It should look like this:

[{
    "embed_code": "<iframe width=\"425\" height=\"349\"
      src=\"http://www.youtube.com/embed/QH2-TGUlwu4\" 
      frameborder=\"0\" allowfullscreen></iframe>",
    "created_at": "2011-10-05T19:16:59Z",
    "title": "The first thing I could think of",
    "updated_at": "2011-10-10T01:04:55Z",
    "id": 1
}]

There’s no magic here; the respond_to block in the index method tells the action to respond to various formats in different ways. When presented with a request for the videos/index resource in HTML format, it uses the format.html method, which by default renders the index.html.erb view template.

When a request for videos/index in JSON format appears, it uses the format.json method, which in this case has a block passed to it. Inside this block is a call to render the @videos instance variable in JSON, which happens internally by calling @videos.to_json

With that in mind, in order to add an RSS feed to the videos/index resource, all we have to do is add another method like format.html or format.json. An easy format for handling RSS feeds is Atom – it’s the simplest specification for RSS feeds to implement and works for what we need to do.

Change the VideosController#index method in app/controllers/videos_controller.rb to look like this:

def index
  @videos = Video.all
  
  respond_to do |format|
    format.html # index.html.erb
    format.json { render :json => @videos }
    format.atom
  end
end

The format.atom method tells the controller to render the matching view template for the action and format requested.

While we could create a view template index.atom.erb and use ERB to generate the output we want, it’s easier to write the view template using Builder, a templating system like ERB, but better suited to forming XML-like documents like Atom. To specify that the view template uses the Builder system, just name the file with a final postfix of .builder instead of .erb

Create the view template app/views/videos/index.atom.builder with the following:

atom_feed do |feed|
  feed.title("Awesome Videos")
  feed.updated(@videos.first.created_at)
              
  @videos.each do |video|
    feed.entry(video) do |entry|
      entry.title(video.title)
      entry.content(sanitize_embed_code(video), :type => 'html')
      
      entry.author do |author|
        author.name("The Awesome Video Group")
      end
    end
  end
end

Visit http://localhost:3000/videos.atom with an RSS reader to see the new video index feed. Figure 2.5, “An RSS reader happily reading videos/index” is an example of what it could look like.

Figure 2.5. An RSS reader happily reading videos/index

Having an RSS feed is great, but it’d be better if it was auto-discoverable by web browsers, giving the user that little “here be RSS” glowing button in the URL like in Figure 2.6, “Safari showing an RSS feed waiting for the taking”.

Figure 2.6. Safari showing an RSS feed waiting for the taking

Making RSS feeds be auto-discoverable is done by adding

<link href="/videos.atom" rel="alternate" title="ATOM" type="application/atom+xml" />

inside the <head> section of each HTML page served up by this application. Rails makes remembering and using these sort of links even easier by providing a view helper that lets you write

<%= auto_discovery_link_tag :atom, videos_path(:atom) %>

but where does it go in order to be in the <head> of each HTML page?

All view templates we’ve looked at have only dealt with content specific to the controller action they were rendering, but where’s the bigger template where the rest get rendered inside of? That bigger template is called a layout template, and in this case, it’s in app/views/layouts/videos.html.erb and looks like this:

<!DOCTYPE html>
<html>
<head>
  <title>VideoJukebox</title>
  <%= stylesheet_link_tag    "application" %>
  <%= javascript_include_tag "application" %>
  <%= csrf_meta_tags %>
</head>
<body>

<%= yield %>

</body>
</html>

The Action View component covered in ??? goes into greater detail about each method used here, but the general idea is that <= yield %> is where rendered HTML view template code appears, and that each controller uses the layout it’s named after (in this case, videos.html.erb) by default.

We want an auto-discoverable RSS link to appear in the <head>, so it’s as simple as inserting the auto-discovery link at the bottom of the <head> section so that app/views/layouts/videos.html.erb looks like:

<!DOCTYPE html>
<html>
<head>

  ...

  <%= auto_discovery_link_tag :atom, videos_path(:atom) %>
</head>

...

Refresh http://localhost:3000/videos and if your browser supports it, you can see a syndication icon appear like in Figure 2.6, “Safari showing an RSS feed waiting for the taking”.

Curious about how all this is working under the hood?

To find out which paths are handled by which controllers’ methods, run rake routes

$ rake routes

    videos GET    /videos(.:format)          {:controller=>"videos", :action=>"index"}
           POST   /videos(.:format)          {:controller=>"videos", :action=>"create"}
 new_video GET    /videos/new(.:format)      {:controller=>"videos", :action=>"new"}
edit_video GET    /videos/:id/edit(.:format) {:controller=>"videos", :action=>"edit"}
     video GET    /videos/:id(.:format)      {:controller=>"videos", :action=>"show"}
           PUT    /videos/:id(.:format)      {:controller=>"videos", :action=>"update"}
           DELETE /videos/:id(.:format)      {:controller=>"videos", :action=>"destroy"}

Note how HTTP verbs are a big deal here – the same /videos path routes to a different action depending if it’s a GET or a POST. This is part of the idea behind RESTful routing. The other important thing to see here is that the paths are predictable and obvious. For example, a HTTP DELETE sent to /videos/1 is a request to delete the video record with id 1.

The :id parts in the paths are placeholders for a record id. Try creating a video and you’ll see that you can visit http://localhost:3000/videos/1 to see it again.

Your application’s routes are configured in config/routes.rb – open it up and take a look at how much code we needed to set up these routes. Actually… just look at this one line the scaffold generator added, because that’s all it takes:

resources :videos

This line is a method call that sets up RESTful routing for the videos resource, where a resource is a term borrowed from REST literature to describe a source of information with a universal identifier and standard interface like the videos URIs in the routing table. REST terminology also dictates that the standard interface be able to exchange representations of the resource. In other words, when you ask for /videos/1, you should get back video 1 in some representation.

The last major piece of functionality we have to implement is the ability to comment on a video. If we treat comments as just another RESTful resource, we can use a generator to fill in a working skeleton of code to fill in and be done quickly.

Instead of using the scaffold generator we used for the videos resource, this time we’re going to use the resource generator – it’s the same as the scaffold generator but doesn’t create view code. Since comments are to be displayed in the video views, we don’t need comment views, so a resource generator is exactly what we need:

rails generate resource Comment body:text

You should see it create a migration, a model, a unit test suite, a fixture, a controller, a functional test suite for the controller, a helper, a test suite for the helper, and an entry in the config/routes.rb file (i.e. a route).

Each video needs to know which comments it has so they can be easily displayed in its view. Likewise, it might be handy for each comment to know which video it belongs to, so let’s set up those associations.

Associations between resources are defined at a model level, so start by editing app/models/comment.rb to look like this:

class Comment < ActiveRecord::Base
  belongs_to :video
end

and change app/models/video.rb to

class Video < ActiveRecord::Base
  has_many :comments
  
  validates :title, :embed_code, :presence => true
  validate :must_have_valid_embed_code
  
  def must_have_valid_embed_code
    unless embed_code.include?("<iframe")
      errors.add(:embed_code, "must include an iframe tag")
    end
  end
end

Before we run the migration the generator wrote for us, we need to edit it so that each comment has a reference to the video it belongs to. In other words, we need to add a foreign key field to hold a video id.

Open up the newly created migration db/migrate/20100313161619_create_comments.rb and edit it so that it looks like this:

class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.text :body
      t.references :video

      t.timestamps
    end
  end
end

That t.references :video line adds the foreign key field video_id to the comments database table.

Run the migration to add the comments table with the columns we specified:

rake db:migrate

Now we need to reflect that association in the routes.

If you look at config/routes.rb you can see the resources :comments line the generator inserted at the top, which routes URIs like http://localhost:3000/comments/5. Check this by running:

$ rake routes

Because each comment belongs to a video, each time a comment is created with that URI, the associated video id would have to be passed in as a parameter. A more elegant way of dealing with hierarchial resource URIs is to use nested resource routes, which produce URIs like http://localhost:3000/videos/1/comments/5 where the parent resource ids (in this case, the video id) are in the path itself.

To nest the comments resource routes within the videos resource change the routes so that the resources :videos line looks like this:

resources :videos do
  resources :comments
end

Check the routes after you make this change by running:

$ rake routes

This should display routes like:

video_comments GET    /videos/:video_id/comments(.:format)
    {:action=>"index", :controller=>"comments"}

The next step is to write the CommentsController#create action. Open up app/controllers/comments_controller.rb and add a public method create so that the class looks like this:

class CommentsController < ApplicationController
  def create
    @video = Video.find params[:video_id]
    @comment = @video.comments.create params[:comment]

    redirect_to @video
  end
end

The last step to make comments work is the view code. Let’s modify the video/show view to allow comment submission and list existing comments for that video. Open up apps/views/videos/show.html.erb and add this around the bottom of the file:

<h2>Please leave a comment:</h2>

<%= form_for([@video, Comment.new], :remote => true) do |f| %>
  <div class="field">
    <%= f.text_area :body, :cols => 40, :rows => 2 %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>

<h2>What others felt about this:</h2>
<div id="comments">
  <% @video.comments.reverse.each do |comment| %>
    <div class="comment">
      <p><%= comment.body %></p>
    </div>
  <% end %>
</div>

Visit http://localhost:3000/, click on a video, then try leaving a comment. Upon refresh, it should appear below the comment form.

While it’s great that VideoHelpers#sanitize_embed_code wraps up data sanitization, what do you do when you need to encapsulate a chunk of a page, like the form used when editing a video in http://localhost:3000/videos/1/edit or when making a new one in http://localhost:3000/videos/new? The answer is to use a partial template, better known as a partial.

Our app renders the same partial in two places, in app/views/videos/new.html.erb:

<h1>New video</h1>
            
<%= render 'form' %>
            
<%= link_to 'Back', videos_path %>

and in app/views/videos/edit.html.erb

<h1>Editing video</h1>
            
<%= render 'form' %>
            
<%= link_to 'Show', @video %> |
<%= link_to 'Back', videos_path %>

That render 'form' line is what renders the partial. All partials have their filename start with an underscore, so this render call is using app/views/videos/_form.html.erb which looks like this:

<%= form_for(@video) do |f| %>
  <% if @video.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@video.errors.count, "error") %> prohibited this video from being saved:</h2>

      <ul>
      <% @video.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= f.label :title %><br />
    <%= f.text_field :title %>
  </div>
  <div class="field">
    <%= f.label :embed_code %><br />
    <%= f.text_area :embed_code %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>

There’s a lot going on here, but the important parts to notice are:

Partials are not only a great fit for displaying the same content in more than one view, but they’re also great for rendering the same bit many times on the same page. See how that works in the Action View chapter, as well as how to use form helpers like form_for, label, text_field, text_area, and submit.

Let’s make a change to the partial to show how making a change in one place will appear in both the videos/new and videos/edit views.

Add a helpful little suggestion for the title field by making this change to app/views/videos/_form.html.erb:

<%= form_for(@video) do |f| %>

  # ...

  <%= f.label :title %> <small>(Be clever!)</small><br />

  # ...

Now take a look at http://localhost:3000/videos/new and http://localhost:3000/videos/1/edit and you should see the single change made in the partial appear in both views.

Let’s make adding comments feel more responsive by adding a sprinkle of AJAX so that newly submitted comments appear on the page right away, without a page refresh.

Rails makes doing this sort of thing super easy. Start by changing the form tag for comments in app/views/videos/show.html.erb to look like this:

<h2>Please leave a comment:</h2>

<%= form_for([@video, Comment.new], :remote => true) do |f| %>
  <div class="field">
  
  ...

The key thing to notice is the addition of the :remote => true option to the form_for call. What that does is it adds a data-remote="true" attribute to the rendered form tag, which is noticed by code in jquery_ujs.js, which unobtrusively turns that form’s submit actions into asynchronous (or async) requests. It’s not important to understand everything that’s going on here; just know that we’re going to have an async call to our app from JavaScript.

Let’s respond to that async JavaScript call from the CommentsController by changing the #create action to respond to requests from JavaScript:

def create
  @video = Video.find params[:video_id]
  @comment = @video.comments.create params[:comment]

  respond_to do |format|
    format.html { redirect_to @video }
    format.js # create.js.erb
  end
end

Just like the .html.erb templates used for the videos, we’re going to create a template to be rendered and passed back as the response to the CommentsController#create action. Create that file now: app/views/comments/create.js.erb

$("#new_comment")[0].reset()
$("#comments").prepend("<%= escape_javascript(@comment.body) %>");

These few lines of jQuery are all we need. The first line resets the form used to create new comments – by default, Rails gives it an HTML id of #new_comment. The second line prepends the comment body to the top of the #comments div. Note that it also escapes the content so it’s safe to embed in JavaScript that’s being sent back as the response to the #create request.

With that added, comments submitted now appear almost instantaneously due to the browser making an async call and rendering the JavaScript received as a response. That’s pretty much all there is to “making things AJAX” in Rails.

For more complex things, just play around with jQuery – there’s tons of great resources on the web and in books. As to what else has the :remote => true option: it also works on form_tag, link_to, and button_to – take a look at ??? for more.

The Rails console is a super handy tool. It loads up your entire application and gives you an irb shell so you can manually play with your application and its data like you were standing inside of it. Here’s an example:

$ rails console
Loading development environment

v = Video.first
=> #<Video id: 1, title: "First thing... >
v.title = "My sweet derpina"
=> "My sweet derpina"
v.save
=> true

During the early stages of app development, the console makes for a really handy admin. It also happens to be super useful for trying out ideas as you can type out one-liners without having to interact with your application from the web, running temporary hacks in the source. Apart from giving you an interactive window into your application, the Rails console also exposes a few interesting variables:

app is an instance of ActionDispatch::Integration::Session which simulates a controller in your application. Here’s an example of playing around with it:

$ rails console
Loading development environment

>> app.url_for(Video.first)
=> "http://www.example.com/videos/1"
>> app.get '/videos/1'
=> 200
>> app.assigns(:video)
=> #<Video id: 1, ... >
>> app.path
=> "/videos/1" 
>> app.reset!
=> nil
>> app.get '/hi/hello/whatever'
=> 404
>> app.post '/videos/1/comments', { :body => 'Trees are great' }
=> 200

The Rails console also gives you access to a local variable called helper that lets you run helper methods. Here are some examples:

$ rails console
Loading development environment

>> helper.pluralize 2, "video"
=> "2 videos"
>> helper.submit_tag
=> "<input name=\"commit\" type=\"submit\" value=\"Save changes\" />"

The console also provides a super handy --sandbox option. Turning this on will cause any database operations to be rolled back upon exiting the console. It’s great for playing around with destructive or mutative operations in ActiveRecord without making permanent changes to the database. Here’s how to turn it on:

$ rails console --sandbox

Need to drop down to the database and tired of remembering the differences of how to do it between SQLite, MySQL and Postgres? Look no further than dbconsole:

$ rails dbconsole
SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> SELECT * FROM comments;
1|Nice video!|1|2011-10-05 19:17:11.192907|2011-10-05 19:17:11.192907

Nice work! You’ve written a typical Rails application from scratch, complete with data sanitization, model validations, an RSS feed, and comments. Not bad.

Think of how long it would take if you had to spend time configuring the guts of an ORM layer, hooking it up to a view templating system, hacking together a routing system, and finding all the rest of the components you might need. Thanks to Rails being a full-stack framework, you didn't have to do any of that.

The rest of this book goes into deeper detail into each part of the Rails stack of components, like Active Record, Action View, Action Controller, and all the other bits and pieces we’ve talked about so far. We’ll be covering the most useful methods and concepts from each and steer you clear of common issues and problems.