Chapter 4. Scaffolding

For centuries, scaffolding has helped builders provide access and support to buildings through the early stages of the construction process. Programmers, too, use temporary scaffolding code to lend structure and support until more permanent code is available. Rails automates scaffolding to make early coding more productive than ever before.

In almost any Ruby on Rails demonstration of five minutes or more, you're likely to see scaffolding. Rails opponents dismiss the feature quickly, saying that any scaffolding code must be thrown away, so the advantages are artificial. In some ways, the detractors are right. Scaffolding user interfaces are ugly and incomplete. But scaffolding provides more than cheap demo thrills. Here are some benefits:

• You can quickly get code in front of your users for feedback.

• You are motivated by faster success.

• You can learn how Rails works by looking at generated code.

• You can use the scaffolding as a foundation to jumpstarts your development.

• You can use metaprogramming that's automatically updated as the structure in the database changes.

In this chapter, we'll show how to use scaffolding to build a primitive user interface for Photo Share. Then, in later chapters, we will extend that foundation to flesh out our application.

Using the Scaffold Method

We've already demonstrated a working model for Photo Share, including photos, categories, slideshows, and slides, and you should be able to manage schema from Active Record objects with the Rails console. The next step is to use scaffolding to build primitive web user interfaces for these classes. Scaffolding will take you a good ways down the road, but it won't generate a completed application. That's okay. We're looking for a head start, not a completed production-quality application.

A List of Photos

Let's start by letting the user manage a list of photos from the Web. Ensure that you've got a database, that it's configured, and that you've got tables with model objects for slides, slideshows, categories, and photos.^[*] If your server is not started, restart it as usual with ruby script/server. Point your browser to http://localhost:3000/ to make sure things are working. You'll see the Rails welcome page if everything is working correctly. Let's build some scaffolding.

You'll start to build scaffolding using the scaffold method. That method goes into the controller, so we need to generate a controller called Photos:

    ruby script/generate controller Photos

Add the scaffold :photo method to photo_controller.rb, like this:

    class PhotosController < ApplicationController
      scaffold :photo
    end

That's all you need—Rails will do the rest. Now, load the URL http://localhost:3000/photos to see the scaffolding in action. You'll see a list of photos, with links to create new photos, edit existing photos, and show existing photos. With the simple scaffold :photo statement, you got all the pages that show in Figure 4-1. The scaffolding generates surprisingly complete controller and view code. To be sure, the scaffolding does not generate production-ready code, but it's a starting point. The next section shows how scaffolding works.

Figure 4-1. Scaffolding renders all four of these views

Tip

If you get the following error when trying to access the application:

    Mysql::Error in Photo#list
    Access denied for user: 'root@localhost' (Using password: NO)

it means that you forgot to restart the server.

More Metaprogramming

scaffold :photo does the magic. scaffold is a method on ActionController.^[†] :photo is a symbol that determines the Active Record model that Rails uses for this scaffold. When you specify this single method, Rails adds to your controller the nine methods in Table 4-1. Four of them render views. Together, the methods build a simple CRUD interface for your Active Record model based on the model object. Within the model, the @@content_columns attribute contains information about each of the columns in the database.

Table 4-1. The scaffold :target method on a Rails controller creates the methods on the controller

Methods	Purpose	View
index	Renders a welcome page. By default, index redirects to the list controller action. Also, by default, when a user specifies a controller but no action, Rails invokes the index action.	No
list	Renders a view with a paginated list of target objects, in which the target object is the model object for the scaffold.	Yes
create(target)	Creates and saves an Active Record object from the target object.	No
new	Renders a view to create a new controller object.	Yes
edit(id)	Renders a view to edit the target object with the supplied id.	Yes
update(id)	Updates the active record target object with the supplied id.	No
show(id)	Renders a view to show an object	Yes
destroy(id)	Destroys the object of type target with the supplied id .	No
render_scaffold	Renders the default view for the view methods if no .rhtml view is present.	N/A

Most of the methods listed in Table 4-1 wind up calling the render_scaffold method, which checks to see whether you've added the corresponding view. (Remember that by default, Rails views will have the same name as the controller method.) If so, Rails uses your views. Otherwise, the controller provides default views.

---

^[*] If you haven't been coding along but wish to start, you can download all of the code through Chapter 3 from the book's web page (http://www.oreilly.com/catalog/rubyrails).

^[†] You can see the actual definition in the Rails source code. scaffold is actually defined on ClassMethods and mixed in as a module to ActionController.