Rails: Up and Running, 2nd Edition

RESTful Routes

Now that you have a working scaffold for photos, we can move on to slides. In this section, we’ll create another default scaffold, but we’ll concentrate on the controllers, and the routes that Rails will use to access each resource. As you recall, a route tells Rails how to interpret an incoming URL. Given a route and a URL, Rails can determine:

• The parameters that Rails will pass to the controller via the params hash

• The controller Rails will access (stored in params[:controller])

• The action that Rails will invoke (stored in params[:action])

Let’s see REST and routes in action. First, generate the scaffolding for a slide:

$ script/generate scaffold slide position:integer photo_id:integer slideshow_id:integer
...
      create  app/views/slides
      create  app/views/slides/index.html.erb
      create  app/views/slides/show.html.erb
      create  app/views/slides/new.html.erb
      create  app/views/slides/edit.html.erb
      create  app/views/layouts/slides.html.erb
...
      create  app/controllers/slides_controller.rb
      create  test/functional/slides_controller_test.rb
...
       route  map.resources :slides
...

As you learned last time, Rails creates a bunch of files for you. This time, we’ll focus on the controllers, views, and the route. As before, a little test data will make it easier to test the application. This time, we’re going to take advantage of templating features. Ruby’s ERb interprets the fixture files just like it does views. Edit test/fixtures/slides.yml to look like this:

<% 1.upto(9) do |i| %> slide_<%= i %>: ...