4.2. Replacing Scaffolding

In many frameworks (such as those that rely completely on code generation), once you replace any of the scaffolding, you take on responsibility for managing all of the scaffolding yourself. Not so with Rails. You can modify or rewrite any single view or controller method without affecting the rest of the scaffolding. For example, let's add a title page through the index method to the PhotosController class:

    class PhotosController < ApplicationController
      scaffold :photo

      def index
        render_text('Welcome to Photo Share\'s Title Page')
      end
    end

Now, load http://localhost:3000/photos/index. You'll see the "Welcome to Photo Share's Title Page" message printed, as in "#rubyrails-chp-4-fig-2">Figure 4-2, which shows that you've overridden the index method provided by the scaffolding.

Figure 4-2. Overriding the index method

Load http://localhost:3000/photos/listto verify that the rest of the scaffolding is still intact. Rails also makes it easy to replace a view while leaving the controller scaffolding intact. Let's replace the view for the show action. Create the file app/views/photos/show.rhtml:

<h1>Show Photos</h1>

<p>filename: <%= @photo.filename %></p>

<%= link_to 'list of photos', :action => 'list', :id => @photo %>

You'll see the view shown in Figure 4-3. As before, you can replace some views and leave the others intact. As you can see, scaffolding stays around until you need to override it. Then it just gradually melts away, a piece at a time, as you replace it.

Figure 4-3. Overriding a scaffolding view

4.2.1. Scaffolding Is Dynamic

You can use Rails scaffolding to provide a simple user interface while you're working on your database schema. Your users can then verify that you're maintaining all of the data you need. Let's see how the Rails scaffolding handles changes in the schema. We'll start by adding columns for a timestamp, a thumbnail, and a description to the photos database table. Create a new migration called add_photo_columns that changes the definition of the photos table by typing ruby script/generate migration add_photo_columns. Edit the resulting migration in db/migrate to look like this:

class AddPhotoColumns < ActiveRecord::Migration
  def self.up
    add_column "photos", "created_at", :datetime
    add_column "photos", "thumbnail", :string
    add_column "photos", "description", :string
    Photo.find(:all).each do |photo|
      photo.update_attribute :created_at, Time.now
      photo.update_attribute :thumbnail, photo.filename.gsub('.', '_m.')
    end
  end
  def self.down
    remove_column "photos", "created_at"
    remove_column "photos", "thumbnail"
    remove_column "photos", "description"
  end
end

This migration script updates the photos table and the data in it. Now, execute the migration by typing rake migrate, and reload your browser (http://localhost:3000/photos/list). You'll see the new columns appear, as in "#rubyrails-chp-4-fig-4">Figure 4-4. In fact, all of the scaffolding views work. So using scaffolding, you can quickly improve your database schema and model without having to focus on your user interface development at the same time.

Figure 4-4. A view created using scaffolding

4.2.2. Pros and Cons

You've just seen how to use scaffolding with the scaffold tag, or the metaprogramming approach. This approach to scaffolding has some critical advantages over other frameworks, like code generation:

• The scaffold tag is dynamic, allowing you the freedom to build on the database schema; the user interface automatically changes to keep up.

• You can override controller methods or views without having to maintain all of the scaffolding yourself.

• The scaffold tag is terse, so you can accomplish much with a single line of code.

In general, the Rails metaprogramming approach provides revolutionary advantages over code generation. Most significantly, dynamic scaffolding continually changes with the surroundings. But the metaprogramming approach does have some core disadvantages as well:

• You can't see what's going on. If you are learning Rails or scaffolding, having the code hidden from you is a distinct disadvantage.

• The behavior of the scaffolding may change with later versions of Rails. This behavior may be a distinct disadvantage if you need to maintain predictability.

• You can't use the scaffolding code as a base for further development.

For these reasons, Rails offers code generation as an alternative method for scaffolding. We'll explore the scaffolding code generator next.