Contents 

Ruby on Rails: Up and Running
Table of Contents
Copyright
Preface
Chapter 1. Zero to Sixty: Introducing Rails
Section 1.1. Rails Strengths
Section 1.2. Putting Rails into Action
Section 1.3. Organization
Section 1.4. The Web Server
Section 1.5. Creating a Controller
Section 1.6. Building a View
Section 1.7. Tying the Controller to the View
Section 1.8. Under the Hood
Section 1.9. What's Next?
Chapter 2. Active Record Basics
Section 2.1. Active Record Basics
Section 2.2. Introducing Photo Share
Section 2.3. Schema Migrations
Section 2.4. Basic Active Record Classes
Section 2.5. Attributes
Section 2.6. Complex Classes
Section 2.7. Behavior
Section 2.8. Moving Forward
Chapter 3. Active Record Relationships
Section 3.1. belongs_to
Section 3.2. has_many
Section 3.3. has_one
Section 3.4. What You Haven't Seen
Section 3.5. Looking Ahead
Chapter 4. Scaffolding
Section 4.1. Using the Scaffold Method
Section 4.2. Replacing Scaffolding
Section 4.3. Generating Scaffolding Code
Section 4.4. Moving Forward
Chapter 5. Extending Views
Section 5.1. The Big Picture
Section 5.2. Seeing Real Photos
Section 5.3. View Templates
Section 5.4. Setting the Default Root
Section 5.5. Stylesheets
Section 5.6. Hierarchical Categories
Section 5.7. Styling the Slideshows
Chapter 6. Ajax
Section 6.1. How Rails Implements Ajax
Section 6.2. Playing a Slideshow
Section 6.3. Using Drag-and-Drop to Reorder Slides
Section 6.4. Drag and Drop Everything (Almost Everything)
Section 6.5. Filtering by Category
Chapter 7. Testing
Section 7.1. Background
Section 7.2. Ruby's Test::Unit
Section 7.3. Testing in Rails
Section 7.4. Wrapping Up
Appendix A. Installing Rails
Section 1.1. Windows
Section 2.1. OS X
Section 3.1. Linux
Appendix B. Quick Reference
Section 5.1. General
Section 5.2. Testing
Section 5.3. RJS (Ruby JavaScript)
Section 5.4. Active Record
Section 5.5. Controllers
Section 5.6. Views
Section 5.7. Ajax
Section 5.8. Configuring Your Application
About the Authors
Colophon
Index
A
B
C
D
E
F
G
H
I
J
L
M
N
O
P
R
S
T
U
V
W
X
Y
Z

Ruby on Rails for all.

Prev Page Next Page
Previous Page
Next Page

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 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 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.


Previous Page
Next Page