From 03bb1ebec513de779908af110c46e16b9c882673 Mon Sep 17 00:00:00 2001
From: Pratik Naik <pratiknaik@gmail.com>
Date: Wed, 4 Feb 2009 01:44:58 +0000
Subject: Convert the guides from asciidoc to textile and integrate with the
 new design.

If you're a guide writer and want to generate the guides, Run :

  ruby railties/guides/rails_guides.rb

And guides HTML will get generated inside railties/guides/output directory.
---
 railties/guides/source/getting_started.textile | 1285 ++++++++++++++++++++++++
 1 file changed, 1285 insertions(+)
 create mode 100644 railties/guides/source/getting_started.textile

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
new file mode 100644
index 0000000000..9dfcc3a3e7
--- /dev/null
+++ b/railties/guides/source/getting_started.textile
@@ -0,0 +1,1285 @@
+h2. Getting Started With Rails
+
+This guide covers getting up and running with Ruby on Rails. After reading it, you should be familiar with:
+
+* Installing Rails, creating a new Rails application, and connecting your application to a database
+* The general layout of a Rails application
+* The basic principles of MVC (Model, View Controller) and RESTful design
+* How to quickly generate the starting pieces of a Rails application.
+
+endprologue.
+
+WARNING. This Guide is based on Rails 2.3. Some of the code shown here will not work in older versions of Rails.
+
+h3. This Guide Assumes
+
+This guide is designed for beginners who want to get started with a Rails application from scratch. It does not assume that you have any prior experience with Rails. However, to get the most out of it, you need to have some prerequisites installed:
+
+* The "Ruby":http://www.ruby-lang.org/en/downloads language
+* The "RubyGems":http://rubyforge.org/frs/?group_id=126 packaging system
+* A working installation of "SQLite":http://www.sqlite.org (preferred), "MySQL":http://www.mysql.com, or "PostgreSQL":http://www.postgresql.org
+
+It is highly recommended that you *familiarize yourself with Ruby before diving into Rails*. You will find it much easier to follow what’s going on with a Rails application if you understand basic Ruby syntax. Rails isn’t going to magically revolutionize the way you write web applications if you have no experience with the language it uses. There are some good free resources on the internet for learning Ruby, including:
+
+* "Mr. Neigborly’s Humble Little Ruby Book":http://www.humblelittlerubybook.com
+* "Programming Ruby":http://www.rubycentral.com/book
+* "Why’s (Poignant) Guide to Ruby":http://poignantguide.net/ruby
+
+h3. What is Rails?
+
+Rails is a web development framework written in the Ruby language. It is designed to make programming web applications easier by making several assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Longtime Rails developers also report that it makes web application development more fun.
+
+Rails is opinionated software. That is, it assumes that there is a best way to do things, and it’s designed to encourage that best way - and in some cases to discourage alternatives. If you learn "The Rails Way" you’ll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.
+
+The Rails philosophy includes several guiding principles:
+
+* DRY - "Don’t Repeat Yourself" - suggests that writing the same code over and over again is a bad thing.
+* Convention Over Configuration - means that Rails makes assumptions about what you want to do and how you’re going to do it, rather than letting you tweak every little thing through endless configuration files.
+* REST is the best pattern for web applications - organizing your application around resources and standard HTTP verbs is the fastest way to go.
+
+h4. The MVC Architecture
+
+Rails is organized around the Model, View, Controller architecture, usually just called MVC. MVC benefits include:
+
+* Isolation of business logic from the user interface
+* Ease of keeping code DRY
+* Making it clear where different types of code belong for easier maintenance
+
+h5. Models
+
+A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, one table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.
+
+h5. Views
+
+Views represent the user interface of your application. In Rails, views are often HTML files with embedded Ruby code that performs tasks related solely to the presentation of the data. Views handle the job of providing data to the web browser or other tool that is used to make requests from your application.
+
+h5. Controllers
+
+Controllers provide the "glue" between models and views. In Rails, controllers are responsible for processing the incoming requests from the web browser, interrogating the models for data, and passing that data on to the views for presentation.
+
+h4. The Components of Rails
+
+Rails provides a full stack of components for creating web applications, including:
+
+* Action Controller
+* Action View
+* Active Record
+* Action Mailer
+* Active Resource
+* Railties
+* Active Support
+
+h5. Action Controller
+
+Action Controller is the component that manages the controllers in a Rails application. The Action Controller framework processes incoming requests to a Rails application, extracts parameters, and dispatches them to the intended action. Services provided by Action Controller include session management, template rendering, and redirect management.
+
+h5. Action View
+
+Action View manages the views of your Rails application. It can create both HTML and XML output by default. Action View manages rendering templates, including nested and partial templates, and includes built-in AJAX support.
+
+h5. Active Record
+
+Active Record is the base for the models in a Rails application. It provides database independence, basic CRUD functionality, advanced finding capabilities, and the ability to relate models to one another, among other services.
+
+h5. Action Mailer
+
+Action Mailer is a framework for building e-mail services. You can use Action Mailer to send emails based on flexible templates, or to receive and process incoming email.
+
+h5. Active Resource
+
+Active Resource provides a framework for managing the connection between business objects an RESTful web services. It implements a way to map web-based resources to local objects with CRUD semantics.
+
+h5. Railties
+
+Railties is the core Rails code that builds new Rails applications and glues the various frameworks together in any Rails application.
+
+h5. Active Support
+
+Active Support is an extensive collection of utility classes and standard Ruby library extensions that are used in the Rails, both by the core code and by your applications.
+
+h4. REST
+
+The foundation of the RESTful architecture is generally considered to be Roy Fielding’s doctoral thesis, "Architectural Styles and the Design of Network-based Software Architectures":http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Fortunately, you need not read this entire document to understand how REST works in Rails. REST, an acronym for Representational State Transfer, boils down to two main principles for our purposes:
+
+* Using resource identifiers (which, for the purposes of discussion, you can think of as URLs) to represent resources
+* Transferring representations of the state of that resource between system components.
+
+For example, to a Rails application a request such as this:
+
+<tt>DELETE /photos/17</tt>
+
+would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities and browser quirks.
+
+If you’d like more details on REST as an architectural style, these resources are more approachable than Fielding’s thesis:
+
+* "A Brief Introduction to REST":http://www.infoq.com/articles/rest-introduction by Stefan Tilkov
+* "An Introduction to REST":http://bitworking.org/news/373/An-Introduction-to-REST (video tutorial) by Joe Gregorio
+* "Representational State Transfer":http://en.wikipedia.org/wiki/Representational_State_Transfer article in Wikipedia
+
+h3. Creating a New Rails Project
+
+If you follow this guide, you’ll create a Rails project called <tt>blog</tt>, a (very) simple weblog. Before you can start building the application, you need to make sure that you have Rails itself installed.
+
+h4. Installing Rails
+
+In most cases, the easiest way to install Rails is to take advantage of RubyGems:
+
+<shell>
+$ gem install rails
+</shell>
+
+NOTE. There are some special circumstances in which you might want to use an alternate installation strategy:
+
+* If you’re working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
+* If you want to keep up with cutting-edge changes to Rails, you’ll want to clone the "Rails source code":http://github.com/rails/rails/tree/master from github. This is not recommended as an option for beginners, though.
+
+h4. Creating the Blog Application
+
+Open a terminal, navigate to a folder where you have rights to create files, and type:
+
+<shell>
+$ rails blog
+</shell>
+
+This will create a Rails application that uses a SQLite database for data storage. If you prefer to use MySQL, run this command instead:
+
+<shell>
+$ rails blog -d mysql
+</shell>
+
+And if you’re using PostgreSQL for data storage, run this command:
+
+<shell>
+$ rails blog -d postgresql
+</shell>
+
+TIP. You can see all of the switches that the Rails application builder accepts by running <tt>rails -h</tt>.
+
+After you create the blog application, switch to its folder to continue work directly in that application:
+
+<shell>
+$ cd blog
+</shell>
+
+In any case, Rails will create a folder in your working directory called <tt>blog</tt>. Open up that folder and explore its contents. Most of the work in this tutorial will happen in the <tt>app/</tt> folder, but here’s a basic rundown on the function of each folder that Rails creates in a new application by default:
+
+|File/Folder|Purpose|
+|README|This is a brief instruction manual for your application. Use it to tell others what your application does, how to set it up, and so on.|
+|Rakefile|This file contains batch jobs that can be run from the terminal.|
+|app/|Contains the controllers, models, and views for your application. You'll focus on this folder for the remainder of this guide.|
+|config/|Configure your application's runtime rules, routes, database, and more.|
+|db/|Shows your current database schema, as well as the database migrations. You'll learn about migrations shortly.|
+|doc/|In-depth documentation for your application.|
+|lib/|Extended modules for your application (not covered in this guide).|
+|log/|Application log files.|
+|public/|The only folder seen to the world as-is.  This is where your images, javascript, stylesheets (CSS), and other static files go.|
+|script/|Scripts provided by Rails to do recurring tasks, such as benchmarking, plugin installation, and starting the console or the web server.|
+|test/|Unit tests, fixtures, and other test apparatus. These are covered in "Testing Rails Applications":testing_rails_applications.html|
+|tmp/|Temporary files|
+|vendor/|A place for third-party code. In a typical Rails application, this includes Ruby Gems, the Rails source code (if you install it into your project) and plugins containing additional prepackaged functionality.|
+
+h4. Configuring a Database
+
+Just about every Rails application will interact with a database. The database to use is specified in a configuration file, +config/database.yml+.
+If you open this file in a new Rails application, you'll see a default database configuration using SQLite. The file contains sections for three different environments in which Rails can run by default:
+
+* The +development+ environment is used on your development computer as you interact manually with the application
+* The +test+ environment is used to run automated tests
+* The +production+ environment is used when you deploy your application for the world to use.
+
+h5. Configuring a SQLite Database
+
+Rails comes with built-in support for "SQLite":http://www.sqlite.org, which is a lightweight serverless database application. While a busy production environment may overload SQLite, it works well for development and testing. Rails defaults to using a SQLite database when creating a new project, but you can always change it later.
+
+Here's the section of the default configuration file with connection information for the development environment:
+
+<yaml>
+development:
+adapter: sqlite3
+database: db/development.sqlite3
+pool: 5
+timeout: 5000
+</yaml>
+
+If you don't have any database set up, SQLite is the easiest to get installed. If you're on OS X 10.5 or greater on a Mac, you already have it. Otherwise, you can install it using RubyGems:
+
+<shell>
+$ gem install sqlite3-ruby
+</shell>
+
+h5. Configuring a MySQL Database
+
+If you choose to use MySQL, your +config/database.yml+ will look a little different. Here's the development section:
+
+<yaml>
+development:
+adapter: mysql
+encoding: utf8
+database: blog_development
+pool: 5
+username: root
+password:
+socket: /tmp/mysql.sock
+</yaml>
+
+If your development computer's MySQL installation includes a root user with an empty password, this configuration should work for you. Otherwise, change the username and password in the +development+ section as appropriate.
+
+h5. Configuring a PostgreSQL Database
+
+If you choose to use PostgreSQL, your +config/database.yml+ will be customized to use PostgreSQL databases:
+
+<yaml>
+development:
+adapter: postgresql
+encoding: unicode
+database: blog_development
+pool: 5
+username: blog
+password:
+</yaml>
+
+Change the username and password in the +development+ section as appropriate.
+
+h4. Creating the Database
+
+Now that you have your database configured, it's time to have Rails create an empty database for you. You can do this by running a rake command:
+
+<shell>
+$ rake db:create
+</shell>
+
+NOTE. Rake is a general-purpose command-runner that Rails uses for many things. You can see the list of available rake commands in your application by running +rake -T+. 
+
+h3. Hello, Rails!
+
+One of the traditional places to start with a new language is by getting some text up on screen quickly. To do that in Rails, you need to create at minimum a controller and a view. Fortunately, you can do that in a single command. Enter this command in your terminal:
+
+<shell>
+$ script/generate controller home index
+</shell>
+
+TIP. If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
+
+Rails will create several files for you, including +app/views/home/index.html.erb+. This is the template that will be used to display the results of the +index+ action (method) in the +home+ controller. Open this file in your text editor and edit it to contain a single line of code:
+
+<code class="html">
+<h1>Hello, Rails!</h1>
+</code>
+
+h4. Starting up the Web Server
+
+You actually have a functional Rails application already - after running only two commands! To see it, you need to start a web server on your development machine. You can do this by running another command:
+
+<shell>
+$ script/server
+</shell>
+
+This will fire up an instance of the Mongrel web server by default (Rails can also use several other web servers). To see your application in action, open a browser window and navigate to +http://localhost:3000+. You should see Rails' default information page:
+
+!images/rails_welcome.png(Welcome Aboard screenshot)!
+
+TIP. To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to stop the server; changes you make in files will be automatically picked up by the server.
+
+The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page. To view the page you just created, navigate to +http://localhost:3000/home/index+.
+
+h4. Setting the Application Home Page
+
+You'd probably like to replace the "Welcome Aboard" page with your own application's home page. The first step to doing this is to delete the default page from your application:
+
+<shell>
+$ rm public/index.html
+</shell>
+
+Now, you have to tell Rails where your actual home page is located. Open the file +config/routes.rb+ in your editor. This is your application's, _routing file_, which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. At the bottom of the file you'll see the _default routes_:
+
+<ruby>
+map.connect ':controller/:action/:id'
+map.connect ':controller/:action/:id.:format'
+</ruby>
+
+The default routes handle simple requests such as +/home/index+: Rails translates that into a call to the +index+ action in the +home+ controller. As another example, +/posts/edit/1+ would run the +edit+ action in the +posts+ controller with an +id+ of 1.
+
+To hook up your home page, you need to add another line to the routing file, above the default routes:
+
+<ruby>
+map.root :controller => "home"
+</ruby>
+
+This line illustrates one tiny bit of the "convention over configuration" approach: if you don't specify an action, Rails assumes the +index+ action.
+
+Now if you navigate to +http://localhost:3000+ in your browser, you'll see the +home/index+ view.
+
+NOTE. For more information about routing, refer to "Rails Routing from the Outside In":routing_outside_in.html.
+
+h3. Getting Up and Running Quickly With Scaffolding
+
+Rails _scaffolding_ is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job. 
+
+h3. Creating a Resource
+
+In the case of the blog application, you can start by generating a scaffolded Post resource: this will represent a single blog posting. To do this, enter this command in your terminal:
+
+<shell>
+$ script/generate scaffold Post name:string title:string content:text
+</shell>
+
+NOTE. While scaffolding will get you up and running quickly, the "one size fits all" code that it generates is unlikely to be a perfect fit for your application. In most cases, you'll need to customize the generated code. Many experienced Rails developers avoid scaffolding entirely, preferring to write all or most of their source code from scratch.
+
+The scaffold generator will build 14 files in your application, along with some folders, and edit one more. Here's a quick overview of what it creates:
+
+|File                                          |Purpose|
+|app/models/post.rb                            |The Post model|
+|db/migrate/20090113124235_create_posts.rb     |Migration to create the posts table in your database (your name will include a different timestamp)|
+|app/views/posts/index.html.erb                |A view to display an index of all posts |
+|app/views/posts/show.html.erb                 |A view to display a single post|
+|app/views/posts/new.html.erb                  |A view to create a new post|
+|app/views/posts/edit.html.erb                 |A view to edit an existing post|
+|app/views/layouts/posts.html.erb              |A view to control the overall look and feel of the other posts views|
+|public/stylesheets/scaffold.css               |Cascading style sheet to make the scaffolded views look better|
+|app/controllers/posts_controller.rb           |The Posts controller|
+|test/functional/posts_controller_test.rb      |Functional testing harness for the posts controller|
+|app/helpers/posts_helper.rb                   |Helper functions to be used from the posts views|
+|config/routes.rb                              |Edited to include routing information for posts|
+|test/fixtures/posts.yml                       |Dummy posts for use in testing|
+|test/unit/post_test.rb                        |Unit testing harness for the posts model|
+|test/unit/helpers/posts_helper_test.rb        |Unit testing harness for the posts helper|
+
+h4. Running a Migration
+
+One of the products of the +script/generate scaffold+ command is a _database migration_. Migrations are Ruby classes that are designed to make it simple to create and modify database tables. Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database. Migration filenames include a timestamp to ensure that they're processed in the order that they were created.
+
+If you look in the +db/migrate/20090113124235_create_posts.rb+ file (remember, yours will have a slightly different name), here's what you'll find:
+
+<ruby>
+class CreatePosts < ActiveRecord::Migration
+  def self.up
+    create_table :posts do |t|
+      t.string :name
+      t.string :title
+      t.text :content
+
+      t.timestamps
+    end
+  end
+
+  def self.down
+    drop_table :posts
+  end
+end
+</ruby>
+
+If you were to translate that into words, it says something like: when this migration is run, create a table named +posts+ with two string columns (+name+ and +title+) and a text column (+content+), and generate timestamp fields to track record creation and updating. You can learn the detailed syntax for migrations in the "Rails Database Migrations":migrations.html guide.
+
+At this point, you can use a rake command to run the migration:
+
+<shell>
+$ rake db:migrate
+</shell>
+
+Remember, you can't run migrations before running +rake db:create+ to create your database, as we covered earlier.
+
+NOTE: Because you're working in the development environment by default, this command will apply to the database defined in the +development+ section of your +config/database.yml+ file.
+
+h4. Adding a Link
+
+To hook the posts up to the home page you've already created, you can add a link to the home page. Open +/app/views/home/index.html.erb+ and modify it as follows:
+
+<code lang="ruby">
+<h1>Hello, Rails!</h1>
+<%= link_to "My Blog", posts_path %>
+
+</code>
+
+The +link_to+ method is one of Rails' built-in view helpers. It creates a hyperlink based on text to display and where to go - in this case, to the path for posts.
+
+h4. Working with Posts in the Browser
+
+Now you're ready to start working with posts. To do that, navigate to +http://localhost:3000+ and then click the "My Blog" link:
+
+!images/posts_index.png(Posts Index screenshot)!
+
+This is the result of Rails rendering the +index+ view of your posts. There aren't currently any posts in the database, but if you click the +New Post+ link you can create one. After that, you'll find that you can edit posts, look at their details, or destroy them. All of the logic and HTML to handle this was built by the single +script/generate scaffold+ command.
+
+TIP. In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server.
+
+Congratulations, you're riding the rails! Now it's time to see how it all works.
+
+h4. The Model
+
+The model file, +app/models/post.rb+ is about as simple as it can get:
+
+<ruby>
+class Post < ActiveRecord::Base
+end
+</ruby>
+
+There isn't much to this file - but note that the +Post+ class inherits from +ActiveRecord::Base+. Active Record supplies a great deal of functionality to your Rails models for free, including basic database CRUD (Create, Read, Update, Destroy) operations, data validation, as well as sophisticated search support and the ability to relate multiple models to one another.
+
+h4. Adding Some Validation
+
+Rails includes methods to help you validate the data that you send to models. Open the +app/models/post.rb+ file and edit it:
+
+<ruby>
+class Post < ActiveRecord::Base
+  validates_presence_of :name, :title
+  validates_length_of :title, :minimum => 5
+end
+</ruby>
+
+These changes will ensure that all posts have a name and a title, and that the title is at least five characters long. Rails can validate a variety of conditions in a model, including the presence or uniqueness of columns, their format, and the existence of associated objects.
+
+h4. Using the Console
+
+To see your validations in action, you can use the console. The console is a command-line tool that lets you execute Ruby code in the context of your application:
+
+<shell>
+$ script/console
+</shell>
+
+After the console loads, you can use it to work with your application's models:
+
+<shell>
+>> p = Post.create(:content => "A new post")
+=> #<Post id: nil, name: nil, title: nil, content: "A new post", 
+created_at: nil, updated_at: nil>
+>> p.save
+=> false
+>> p.errors
+=> #<ActiveRecord::Errors:0x23bcf0c @base=#<Post id: nil, name: nil, 
+title: nil, content: "A new post", created_at: nil, updated_at: nil>, 
+@errors={"name"=>["can't be blank"], "title"=>["can't be blank", 
+"is too short (minimum is 5 characters)"]}>
+</shell>
+
+This code shows creating a new +Post+ instance, attempting to save it and getting +false+ for a return value (indicating that the save failed), and inspecting the +errors+ of the post.
+
+TIP: Unlike the development web server, the console does not automatically load your code afresh for each line. If you make changes to your models while the console is open, type +reload!+ at the console prompt to load them.
+
+h4. Listing All Posts
+
+The easiest place to start looking at functionality is with the code that lists all posts. Open the file +app/controllers/posts_controller.rb + and look at the +index+ action:
+
+<ruby>
+def index
+  @posts = Post.find(:all)
+
+  respond_to do |format|
+    format.html # index.html.erb
+    format.xml  { render :xml => @posts }
+  end
+end
+</ruby>
+
+This code sets the +@posts+ instance variable to an array of all posts in the database. +Post.find(:all)+ or +Post.all+ calls the +Post+ model to return all of the posts that are currently in the database, with no limiting conditions.
+
+TIP. For more information on finding records with Active Record, see "Active Record Finders":finders.html.
+
+The +respond_to+ block handles both HTML and XML calls to this action. If you browse to +http://localhost:3000/posts.xml+, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/view/posts/index.html.erb+:
+
+<erb>
+<h1>Listing posts</h1>
+
+<table>
+  <tr>
+    <th>Name</th>
+    <th>Title</th>
+    <th>Content</th>
+  </tr>
+
+<% for post in @posts %>
+  <tr>
+    <td><%=h post.name %></td>
+    <td><%=h post.title %></td>
+    <td><%=h post.content %></td>
+    <td><%= link_to 'Show', post %></td>
+    <td><%= link_to 'Edit', edit_post_path(post) %></td>
+    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %></td>
+  </tr>
+<% end %>
+</table>
+
+<br />
+
+<%= link_to 'New post', new_post_path %>
+</erb>
+
+This view iterates over the contents of the +@posts+ array to display content and links. A few things to note in the view:
+
+* +h+ is a Rails helper method to sanitize displayed data, preventing cross-site scripting attacks
+* +link_to+ builds a hyperlink to a particular destination
+* +edit_post_path+ is a helper that Rails provides as part of RESTful routing. You’ll see a variety of these helpers for the different actions that the controller includes.
+
+TIP. For more details on the rendering process, see "Layouts and Rendering in Rails":layouts_and_rendering.html.
+
+h4. Customizing the Layout
+
+The view is only part of the story of how HTML is displayed in your web browser. Rails also has the concept of +layouts+, which are containers for views. When Rails renders a view to the browser, it does so by putting the view's HTML into a layout's HTML. The +script/generate scaffold+ command automatically created a default layout, +app/views/layouts/posts.html.erb+, for the posts. Open this layout in your editor and modify the +body+ tag:
+
+<erb>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+  <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
+  <title>Posts: <%= controller.action_name %></title>
+  <%= stylesheet_link_tag 'scaffold' %>
+</head>
+<body style="background: #EEEEEE;">
+
+<p style="color: green"><%= flash[:notice] %></p>
+
+<%= yield  %>
+
+</body>
+</html>
+</erb>
+
+Now when you refresh the +/posts+ page, you'll see a gray background to the page. This same gray background will be used throughout all the views for posts.
+
+h4. Creating New Posts
+
+Creating a new post involves two actions. The first is the +new+ action, which instantiates an empty +Post+ object:
+
+<ruby>
+def new
+  @post = Post.new
+
+  respond_to do |format|
+    format.html # new.html.erb
+    format.xml  { render :xml => @post }
+  end
+end
+</ruby>
+
+The +new.html.erb+ view displays this empty Post to the user:
+
+<erb>
+<h1>New post</h1>
+
+<% form_for(@post) do |f| %>
+  <%= f.error_messages %>
+
+  <p>
+    <%= f.label :name %><br />
+    <%= f.text_field :name %>
+  </p>
+  <p>
+    <%= f.label :title %><br />
+    <%= f.text_field :title %>
+  </p>
+  <p>
+    <%= f.label :content %><br />
+    <%= f.text_area :content %>
+  </p>
+  <p>
+    <%= f.submit "Create" %>
+  </p>
+<% end %>
+
+<%= link_to 'Back', posts_path %>
+</erb>
+
+The +form_for+ block is used to create an HTML form. Within this block, you have access to methods to build various controls on the form. For example, +f.text_field :name+ tells Rails to create a text input on the form, and to hook it up to the +name+ attribute of the instance being displayed. You can only use these methods with attributes of the model that the form is based on (in this case +name+, +title+, and +content+). Rails uses +form_for+ in preference to having your write raw HTML because the code is more succinct, and because it explicitly ties the form to a particular model instance.
+
+TIP: If you need to create an HTML form that displays arbitrary fields, not tied to a model, you should use the +form_tag+ method, which provides shortcuts for building forms that are not necessarily tied to a model instance.
+
+When the user clicks the +Create+ button on this form, the browser will send information back to the +create+ method of the controller (Rails knows to call the +create+ method because the form is sent with an HTTP POST request; that's one of the conventions that I mentioned earlier):
+
+<ruby>
+def create
+  @post = Post.new(params[:post])
+
+  respond_to do |format|
+    if @post.save
+      flash[:notice] = 'Post was successfully created.'
+      format.html { redirect_to(@post) }
+      format.xml  { render :xml => @post, :status => :created, :location => @post }
+    else
+      format.html { render :action => "new" }
+      format.xml  { render :xml => @post.errors, :status => :unprocessable_entity }
+    end
+  end
+end
+</ruby>
+
+The +create+ action instantiates a new Post object from the data supplied by the user on the form, which Rails makes available in the +params+ hash. After saving the new post, it uses +flash[:notice]+ to create an informational message for the user, and redirects to the show action for the post. If there's any problem, the +create+ action just shows the +new+ view a second time, with any error messages.
+
+Rails provides the +flash+ hash (usually just called the Flash) so that messages can be carried over to another action, providing the user with useful information on the status of their request.  In the case of +create+, the user never actually sees any page rendered during the Post creation process, because it immediately redirects to the new Post as soon Rails saves the record. The Flash carries over a message to the next action, so that when the user is redirected back to the +show+ action, they are presented with a message saying "Post was successfully created."
+
+h4. Showing an Individual Post
+
+When you click the +show+ link for a post on the index page, it will bring you to a URL like +http://localhost:3000/posts/1+. Rails interprets this as a call to the +show+ action for the resource, and passes in +1+ as the +:id+ parameter. Here's the +show+ action:
+
+<ruby>
+def show
+  @post = Post.find(params[:id])
+
+  respond_to do |format|
+    format.html # show.html.erb
+    format.xml  { render :xml => @post }
+  end
+end
+</ruby>
+
+The +show+ action uses +Post.find+ to search for a single record in the database by its id value. After finding the record, Rails displays it by using +show.html.erb+:
+
+<erb>
+<p>
+  <b>Name:</b>
+  <%=h @post.name %>
+</p>
+
+<p>
+  <b>Title:</b>
+  <%=h @post.title %>
+</p>
+
+<p>
+  <b>Content:</b>
+  <%=h @post.content %>
+</p>
+
+
+<%= link_to 'Edit', edit_post_path(@post) %> |
+<%= link_to 'Back', posts_path %>
+</erb>
+
+h4. Editing Posts
+
+Like creating a new post, editing a post is a two-part process. The first step is a request to +edit_post_path(@post)+ with a particular post. This calls the +edit+ action in the controller:
+
+<ruby>
+def edit
+  @post = Post.find(params[:id])
+end
+</ruby>
+
+After finding the requested post, Rails uses the +edit.html.erb+ view to display it:
+
+<erb>
+<h1>Editing post</h1>
+
+<% form_for(@post) do |f| %>
+  <%= f.error_messages %>
+
+  <p>
+    <%= f.label :name %><br />
+    <%= f.text_field :name %>
+  </p>
+  <p>
+    <%= f.label :title %><br />
+    <%= f.text_field :title %>
+  </p>
+  <p>
+    <%= f.label :content %><br />
+    <%= f.text_area :content %>
+  </p>
+  <p>
+    <%= f.submit "Update" %>
+  </p>
+<% end %>
+
+<%= link_to 'Show', @post %> |
+<%= link_to 'Back', posts_path %>
+</erb>
+
+Submitting the form created by this view will invoke the +update+ action within the controller:
+
+<ruby>
+def update
+  @post = Post.find(params[:id])
+
+  respond_to do |format|
+    if @post.update_attributes(params[:post])
+      flash[:notice] = 'Post was successfully updated.'
+      format.html { redirect_to(@post) }
+      format.xml  { head :ok }
+    else
+      format.html { render :action => "edit" }
+      format.xml  { render :xml => @post.errors, :status => :unprocessable_entity }
+    end
+  end
+end
+</ruby>
+
+In the +update+ action, Rails first uses the +:id+ parameter passed back from the edit view to locate the database record that's being edited. The +update_attributes+ call then takes the rest of the parameters from the request and applies them to this record. If all goes well, the user is redirected to the post's +show+ view. If there are any problems, it's back to +edit+ to correct them.
+
+NOTE. Sharp-eyed readers will have noticed that the +form_for+ declaration is identical for the +new+ and +edit+ views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a _partial template_, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that’s easy to modify if you want different forms for +create+ and +edit+.
+
+h4. Destroying a Post
+
+Finally, clicking one of the +destroy+ links sends the associated id to the +destroy+ action:
+
+<ruby>
+def destroy
+  @post = Post.find(params[:id])
+  @post.destroy
+
+  respond_to do |format|
+    format.html { redirect_to(posts_url) }
+    format.xml  { head :ok }
+  end
+end
+</ruby>
+
+The +destroy+ method of an Active Record model instance removes the corresponding record from the database. After that's done, there isn't any record to display, so Rails redirects the user's browser to the index view for the model.
+
+h3. DRYing up the Code
+
+At this point, it’s worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views and _filters_ to help with duplication in controllers.
+
+h4. Using Partials to Eliminate View Duplication
+
+As you saw earlier, the scaffold-generated views for the +new+ and +edit+ actions are largely identical. You can pull the shared code out into a partial template. This requires editing the new and edit views, and adding a new template. The new +_form.html.erb+ template should be saved in the same +app/views/posts+ folder as the files from which it is being extracted. Note that the name of this file begins with an underscore; that's the Rails naming convention for partial templates.
+
++new.html.erb+:
+
+<html>
+<h1>New post</h1>
+
+<%= render :partial => "form" %>
+
+<%= link_to 'Back', posts_path %>
+</html>
+
++edit.html.erb+:
+
+<erb>
+<h1>Editing post</h1>
+
+<%= render :partial => "form" %>
+
+<%= link_to 'Show', @post %> |
+<%= link_to 'Back', posts_path %>
+</erb>
+
++_form.html.erb+:
+
+<erb>
+<% form_for(@post) do |f| %>
+  <%= f.error_messages %>
+
+  <p>
+    <%= f.label :name %><br />
+    <%= f.text_field :name %>
+  </p>
+  <p>
+    <%= f.label :title, "title" %><br />
+    <%= f.text_field :title %>
+  </p>
+  <p>
+    <%= f.label :content %><br />
+    <%= f.text_area :content %>
+  </p>
+  <p>
+    <%= f.submit "Save" %>
+  </p>
+<% end %>
+</erb>
+
+Now, when Rails renders the +new+ or +edit+ view, it will insert the +_form+ partial at the indicated point. Note the naming convention for partials: if you refer to a partial named +form+ inside of a view, the corresponding file is +_form.html.erb+, with a leading underscore.
+
+For more information on partials, refer to the "Layouts and Rending in Rails":layouts_and_rendering.html guide.
+
+h4. Using Filters to Eliminate Controller Duplication
+
+At this point, if you look at the controller for posts, you’ll see some duplication:
+
+<ruby>
+class PostsController < ApplicationController
+  # ...
+  def show
+    @post = Post.find(params[:id])
+  # ... 
+  end
+
+  def edit
+    @post = Post.find(params[:id])
+  end
+
+  def update
+    @post = Post.find(params[:id])
+    # ...
+  end
+
+  def destroy
+    @post = Post.find(params[:id])
+    # ...
+  end
+end
+</ruby>
+
+Four instances of the exact same line of code doesn’t seem very DRY. Rails provides _filters_ as a way to address this sort of repeated code. In this case, you can DRY things up by using a +before_filter+:
+
+<ruby>
+class PostsController < ApplicationController
+  before_filter :find_post, :only => [:show, :edit, :update, :destroy]
+  # ...
+  def show
+  # ... 
+  end
+
+  def edit
+  end
+
+  def update
+    # ...
+  end
+
+  def destroy
+    # ...
+  end
+
+  private
+    def find_post
+      @post = Post.find(params[:id])
+    end
+end
+</ruby>
+
+Rails runs _before filters_ before any action in the controller. You can use the +:only+ clause to limit a before filter to only certain actions, or an +:except+ clause to specifically skip a before filter for certain actions. Rails also allows you to define _after filters_ that run after processing an action, as well as _around filters_ that surround the processing of actions. Filters can also be defined in external classes to make it easy to share them between controllers.
+
+For more information on filters, see the "Action Controller Basics":actioncontroller_basics.html guide.
+
+h3. Adding a Second Model
+
+Now that you've seen what's in a model built with scaffolding, it's time to add a second model to the application. The second model will handle comments on blog posts.
+
+h4. Generating a Model 
+
+Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:
+
+<shell>
+$ script/generate model Comment commenter:string body:text post:references
+</shell>
+
+This command will generate four files:
+
+* +app/models/comment.rb+ - The model
+* +db/migrate/20091013214407_create_comments.rb+ - The migration
+* +test/unit/comment_test.rb+ and +test/fixtures/comments.yml+ - The test harness.
+
+First, take a look at +comment.rb+:
+
+<ruby>
+class Comment < ActiveRecord::Base
+  belongs_to :post
+end
+</ruby>
+
+This is very similar to the +post.rb+ model that you saw earlier. The difference is the line +belongs_to :post+, which sets up an Active Record _association_. You'll learn a little about associations in the next section of this guide.
+
+In addition to the model, Rails has also made a migration to create the corresponding database table:
+
+<ruby>
+class CreateComments < ActiveRecord::Migration
+  def self.up
+    create_table :comments do |t|
+      t.string :commenter
+      t.text :body
+      t.references :post
+
+      t.timestamps
+    end
+  end
+
+  def self.down
+    drop_table :comments
+  end
+end
+</ruby>
+
+The +t.references+ line sets up a foreign key column for the association between the two models. Go ahead and run the migration:
+
+<shell>
+$ rake db:migrate
+</shell>
+
+Rails is smart enough to only execute the migrations that have not already been run against the current database.
+
+h4. Associating Models
+
+Active Record associations let you easily declare the relationship between two models. In the case of comments and posts, you could write out the relationships this way:
+
+* Each comment belongs to one post
+* One post can have many comments
+
+In fact, this is very close to the syntax that Rails uses to declare this association. You've already seen the line of code inside the Comment model that makes each comment belong to a Post:
+
+<ruby>
+class Comment < ActiveRecord::Base
+  belongs_to :post
+end
+</ruby>
+
+You'll need to edit the +post.rb+ file to add the other side of the association:
+
+<ruby>
+class Post < ActiveRecord::Base
+  validates_presence_of :name, :title
+  validates_length_of :title, :minimum => 5
+  has_many :comments
+end
+</ruby>
+
+These two declarations enable a good bit of automatic behavior. For example, if you have an instance variable +@post+ containing a post, you can retrieve all the comments belonging to that post as the array +@post.comments+.
+
+TIP: For more information on Active Record associations, see the "Active Record Associations":association_basics.html guide.
+
+h4. Adding a Route
+
+_Routes_ are entries in the +config/routes.rb+ file that tell Rails how to match incoming HTTP requests to controller actions. Open up that file and find the existing line referring to +posts+ (it will be right at the top of the file). Then edit it as follows:
+
+<ruby>
+map.resources :posts, :has_many => :comments
+</ruby>
+
+This creates +comments+ as a _nested resource_ within +posts+. This is another part of capturing the hierarchical relationship that exists between posts and comments.
+
+TIP: For more information on routing, see the "Rails Routing from the Outside In":routing_outside_in.html guide.
+
+h4. Generating a Controller
+
+With the model in hand, you can turn your attention to creating a matching controller. Again, there's a generator for this:
+
+<shell>
+$ script/generate controller Comments index show new edit
+</shell>
+
+This creates seven files:
+
+* +app/controllers/comments_controller.rb+ - The controller
+* +app/helpers/comments_helper.rb+ - A view helper file
+* +app/views/comments/index.html.erb+ - The view for the index action
+* +app/views/comments/show.html.erb+ - The view for the show action
+* +app/views/comments/new.html.erb+ - The view for the new action
+* +app/views/comments/edit.html.erb+ - The view for the edit action
+* +test/functional/comments_controller_test.rb+ - The functional tests for the controller
+
+The controller will be generated with empty methods and views for each action that you specified in the call to +script/generate controller+:
+
+<ruby>
+class CommentsController < ApplicationController
+  def index
+  end
+
+  def show
+  end
+
+  def new
+  end
+
+  def edit
+  end
+
+end
+</ruby>
+
+You'll need to flesh this out with code to actually process requests appropriately in each method. Here's a version that (for simplicity's sake) only responds to requests that require HTML:
+
+<ruby>
+class CommentsController < ApplicationController
+  def index
+    @post = Post.find(params[:post_id])
+    @comments = @post.comments
+  end
+
+  def show
+    @post = Post.find(params[:post_id])
+    @comment = @post.comments.find(params[:id])
+  end
+
+  def new
+    @post = Post.find(params[:post_id])
+    @comment = @post.comments.build
+  end
+
+  def create
+    @post = Post.find(params[:post_id])
+    @comment = @post.comments.build(params[:comment])
+    if @comment.save
+      redirect_to post_comment_url(@post, @comment)
+    else
+      render :action => "new"
+    end
+  end
+  
+  def edit
+    @post = Post.find(params[:post_id])
+    @comment = @post.comments.find(params[:id])
+  end
+
+  def update
+    @post = Post.find(params[:post_id])
+    @comment = Comment.find(params[:id])
+    if @comment.update_attributes(params[:comment])
+      redirect_to post_comment_url(@post, @comment)
+    else
+      render :action => "edit"
+    end
+  end
+
+  def destroy
+    @post = Post.find(params[:post_id])
+    @comment = Comment.find(params[:id])
+    @comment.destroy
+
+    respond_to do |format|
+      format.html { redirect_to post_comments_path(@post) }
+      format.xml  { head :ok }
+    end
+  end
+
+end
+</ruby>
+
+You'll see a bit more complexity here than you did in the controller for posts. That's a side-effect of the nesting that you've set up; each request for a comment has to keep track of the post to which the comment is attached.
+
+In addition, the code takes advantage of some of the methods available for an association. For example, in the +new+ method, it calls
+
+<ruby>
+@comment = @post.comments.build
+</ruby>
+
+This creates a new +Comment+ object _and_ sets up the +post_id+ field to have the +id+ from the specified +Post+ object in a single operation.
+
+h4. Building Views
+
+Because you skipped scaffolding, you'll need to build views for comments "by hand." Invoking +script/generate controller+ will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.
+
+The +views/comments/index.html.erb+ view:
+
+<erb>
+<h1>Comments for <%= @post.title %></h1>
+
+<table>
+  <tr>
+    <th>Commenter</th>
+    <th>Body</th>
+  </tr>
+
+<% for comment in @comments %>
+  <tr>
+    <td><%=h comment.commenter %></td>
+    <td><%=h comment.body %></td>
+    <td><%= link_to 'Show', post_comment_path(@post, comment) %></td>
+    <td><%= link_to 'Edit', edit_post_comment_path(@post, comment) %></td>
+    <td><%= link_to 'Destroy', post_comment_path(@post, comment), :confirm => 'Are you sure?', :method => :delete %></td>
+  </tr>
+<% end %>
+</table>
+
+<br />
+
+<%= link_to 'New comment', new_post_comment_path(@post) %>
+<%= link_to 'Back to Post', @post %>
+</erb>
+
+The +views/comments/new.html.erb+ view:
+
+<erb>
+<h1>New comment</h1>
+
+<% form_for([@post, @comment]) do |f| %>
+  <%= f.error_messages %>
+
+  <p>
+    <%= f.label :commenter %><br />
+    <%= f.text_field :commenter %>
+  </p>
+  <p>
+    <%= f.label :body %><br />
+    <%= f.text_area :body %>
+  </p>
+  <p>
+    <%= f.submit "Create" %>
+  </p>
+<% end %>
+
+<%= link_to 'Back', post_comments_path(@post) %>
+</erb>
+
+The +views/comments/show.html.erb+ view:
+
+<erb>
+<h1>Comment on <%= @post.title %></h1>
+
+<p>
+  <b>Commenter:</b>
+  <%=h @comment.commenter %>
+</p>
+
+<p>
+  <b>Comment:</b>
+  <%=h @comment.body %>
+</p>
+
+<%= link_to 'Edit', edit_post_comment_path(@post, @comment) %> |
+<%= link_to 'Back', post_comments_path(@post) %>
+</erb>
+
+The +views/comments/edit.html.erb+ view:
+
+<erb>
+<h1>Editing comment</h1>
+
+<% form_for([@post, @comment]) do |f| %>
+  <%= f.error_messages %>
+
+  <p>
+    <%= f.label :commenter %><br />
+    <%= f.text_field :commenter %>
+  </p>
+  <p>
+    <%= f.label :body %><br />
+    <%= f.text_area :body %>
+  </p>
+  <p>
+    <%= f.submit "Update" %>
+  </p>
+<% end %>
+
+<%= link_to 'Show', post_comment_path(@post, @comment) %> |
+<%= link_to 'Back', post_comments_path(@post) %>
+</erb>
+
+Again, the added complexity here (compared to the views you saw for managing posts) comes from the necessity of juggling a post and its comments at the same time.
+
+h4. Hooking Comments to Posts
+
+As a next step, I'll modify the +views/posts/show.html.erb+ view to show the comments on that post, and to allow managing those comments:
+
+<erb>
+<p>
+  <b>Name:</b>
+  <%=h @post.name %>
+</p>
+
+<p>
+  <b>Title:</b>
+  <%=h @post.title %>
+</p>
+
+<p>
+  <b>Content:</b>
+  <%=h @post.content %>
+</p>
+
+<h2>Comments</h2>
+<% @post.comments.each do |c| %>
+  <p>
+    <b>Commenter:</b>
+    <%=h c.commenter %>
+  </p>
+
+  <p>
+    <b>Comment:</b>
+    <%=h c.body %>
+  </p>
+<% end %>
+
+<%= link_to 'Edit Post', edit_post_path(@post) %> |
+<%= link_to 'Back to Posts', posts_path %> |
+<%= link_to 'Manage Comments', post_comments_path(@post) %>
+</erb>
+
+Note that each post has its own individual comments collection, accessible as +@post.comments+. That's a consequence of the declarative associations in the models. Path helpers such as +post_comments_path+ come from the nested route declaration in +config/routes.rb+.
+
+h3. Building a Multi-Model Form
+
+Comments and posts are edited on two separate forms - which makes sense, given the flow of this mini-application. But what if you want to edit more than one thing on a single form? Rails 2.3 offers new support for nested forms. Let's add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
+
+<shell>
+$ script/generate model tag name:string post:references
+</shell>
+
+Run the migration to create the database table:
+
+<shell>
+$ rake db:migrate
+</shell>
+
+Next, edit the +post.rb+ file to create the other side of the association, and to tell Rails that you intend to edit tags via posts:
+
+<ruby>
+class Post < ActiveRecord::Base
+  validates_presence_of :name, :title
+  validates_length_of :title, :minimum => 5
+  has_many :comments
+  has_many :tags
+  
+  accepts_nested_attributes_for :tags, :allow_destroy => :true  ,
+    :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }
+end
+</ruby>
+
+The +:allow_destroy+ option on the nested attribute declaration tells Rails to display a "remove" checkbox on the view that you'll build shortly. The +:reject_if+ option prevents saving new tags that do not have any attributes filled in.
+
+You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
+
+<erb>
+<% @post.tags.build if @post.tags.empty? %>
+<% form_for(@post) do |post_form| %>
+  <%= post_form.error_messages %>
+
+  <p>
+    <%= post_form.label :name %><br />
+    <%= post_form.text_field :name %>
+  </p>
+  <p>
+    <%= post_form.label :title, "title" %><br />
+    <%= post_form.text_field :title %>
+  </p>
+  <p>
+    <%= post_form.label :content %><br />
+    <%= post_form.text_area :content %>
+  </p>
+  <h2>Tags</h2>
+  <% post_form.fields_for :tags do |tag_form| %>
+    <p>
+      <%= tag_form.label :name, 'Tag:' %>
+      <%= tag_form.text_field :name %>
+    </p>
+    <% unless tag_form.object.nil? || tag_form.object.new_record? %>
+      <p>
+        <%= tag_form.label :_delete, 'Remove:' %>
+        <%= tag_form.check_box :_delete %>
+      </p>
+    <% end %>
+  <% end %>
+
+  <p>
+    <%= post_form.submit "Save" %>
+  </p>
+<% end %>
+</erb>
+
+With these changes in place, you'll find that you can edit a post and its tags directly on the same view.
+
+NOTE. You may want to use javascript to dynamically add additional tags on a single form. For an example of this and other advanced techniques, see the "nested model sample application":http://github.com/alloy/complex-form-examples/tree/nested_attributes.
+
+h3. What's Next?
+
+Now that you've seen your first Rails application, you should feel free to update it and experiment on your own. But you don't have to do everything without help. As you need assistance getting up and running with Rails, feel free to consult these support resources:
+
+* The "Ruby On Rails guides":http://guides.rubyonrails.org
+* The "Ruby on Rails mailing list":http://groups.google.com/group/rubyonrails-talk
+* The #rubyonrails channel on irc.freenode.net
+
+Rails also comes with built-in help that you can generate using the rake command-line utility:
+
+* Running +rake doc:guides+ will put a full copy of the Rails Guides in the +/doc/guides+ folder of your application. Open +/doc/guides/index.html+ in your web browser to explore the Guides.
+* Running +rake doc:rails+ will put a full copy of the API documentation for Rails in the +/doc/api+ folder of your application. Open +/doc/api/index.html+ in your web browser to explore the API documentation.
+
+h3. Changelog
+
+"Lighthouse ticket":http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2
+
+* February 1, 2009: Updated for Rails 2.3 by "Mike Gunderloy":credits.html#mgunderloy
+* November 3, 2008: Formatting patch from Dave Rothlisberger
+* November 1, 2008: First approved version by "Mike Gunderloy":credits.html#mgunderloy
+* October 16, 2008: Revised based on feedback from Pratik Naik by "Mike Gunderloy":credits.html#mgunderloy (not yet approved for publication)
+* October 13, 2008: First complete draft by "Mike Gunderloy":credits.html#mgunderloy (not yet approved for publication)
+* October 12, 2008: More detail, rearrangement, editing by "Mike Gunderloy":credits.html#mgunderloy (not yet approved for publication)
+* September 8, 2008: initial version by James Miller (not yet approved for publication)
\ No newline at end of file
-- 
cgit v1.2.3


From 7b0a1751376af0f8323aa0ccbd9616d7bed6ed84 Mon Sep 17 00:00:00 2001
From: Mike Gunderloy <MikeG1@larkfarm.com>
Date: Wed, 4 Feb 2009 07:46:57 -0600
Subject: Formatting fixes for Getting Started guide

---
 railties/guides/source/getting_started.textile | 38 +++++++++++++++++---------
 1 file changed, 25 insertions(+), 13 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 9dfcc3a3e7..bdd2a9d429 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -472,7 +472,7 @@ end
 
 This code sets the +@posts+ instance variable to an array of all posts in the database. +Post.find(:all)+ or +Post.all+ calls the +Post+ model to return all of the posts that are currently in the database, with no limiting conditions.
 
-TIP. For more information on finding records with Active Record, see "Active Record Finders":finders.html.
+TIP: For more information on finding records with Active Record, see "Active Record Finders":finders.html.
 
 The +respond_to+ block handles both HTML and XML calls to this action. If you browse to +http://localhost:3000/posts.xml+, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/view/posts/index.html.erb+:
 
@@ -493,7 +493,8 @@ The +respond_to+ block handles both HTML and XML calls to this action. If you br
     <td><%=h post.content %></td>
     <td><%= link_to 'Show', post %></td>
     <td><%= link_to 'Edit', edit_post_path(post) %></td>
-    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %></td>
+    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', 
+            :method => :delete %></td>
   </tr>
 <% end %>
 </table>
@@ -521,7 +522,8 @@ The view is only part of the story of how HTML is displayed in your web browser.
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
-  <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
+  <meta http-equiv="content-type" 
+        content="text/html;charset=UTF-8" />
   <title>Posts: <%= controller.action_name %></title>
   <%= stylesheet_link_tag 'scaffold' %>
 </head>
@@ -594,10 +596,12 @@ def create
     if @post.save
       flash[:notice] = 'Post was successfully created.'
       format.html { redirect_to(@post) }
-      format.xml  { render :xml => @post, :status => :created, :location => @post }
+      format.xml  { render :xml => @post, :status => :created, 
+	                :location => @post }
     else
       format.html { render :action => "new" }
-      format.xml  { render :xml => @post.errors, :status => :unprocessable_entity }
+      format.xml  { render :xml => @post.errors, 
+	                :status => :unprocessable_entity }
     end
   end
 end
@@ -697,7 +701,8 @@ def update
       format.xml  { head :ok }
     else
       format.html { render :action => "edit" }
-      format.xml  { render :xml => @post.errors, :status => :unprocessable_entity }
+      format.xml  { render :xml => @post.errors, 
+	                :status => :unprocessable_entity }
     end
   end
 end
@@ -733,7 +738,7 @@ h4. Using Partials to Eliminate View Duplication
 
 As you saw earlier, the scaffold-generated views for the +new+ and +edit+ actions are largely identical. You can pull the shared code out into a partial template. This requires editing the new and edit views, and adding a new template. The new +_form.html.erb+ template should be saved in the same +app/views/posts+ folder as the files from which it is being extracted. Note that the name of this file begins with an underscore; that's the Rails naming convention for partial templates.
 
-+new.html.erb+:
+<tt>new.html.erb</tt>:
 
 <html>
 <h1>New post</h1>
@@ -743,7 +748,7 @@ As you saw earlier, the scaffold-generated views for the +new+ and +edit+ action
 <%= link_to 'Back', posts_path %>
 </html>
 
-+edit.html.erb+:
+<tt>edit.html.erb</tt>:
 
 <erb>
 <h1>Editing post</h1>
@@ -754,7 +759,7 @@ As you saw earlier, the scaffold-generated views for the +new+ and +edit+ action
 <%= link_to 'Back', posts_path %>
 </erb>
 
-+_form.html.erb+:
+<tt>_form.html.erb</tt>:
 
 <erb>
 <% form_for(@post) do |f| %>
@@ -814,7 +819,8 @@ Four instances of the exact same line of code doesn’t seem very DRY. Rails pro
 
 <ruby>
 class PostsController < ApplicationController
-  before_filter :find_post, :only => [:show, :edit, :update, :destroy]
+  before_filter :find_post, 
+    :only => [:show, :edit, :update, :destroy]
   # ...
   def show
   # ... 
@@ -851,7 +857,8 @@ h4. Generating a Model
 Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:
 
 <shell>
-$ script/generate model Comment commenter:string body:text post:references
+$ script/generate model Comment commenter:string body:text 
+    post:references
 </shell>
 
 This command will generate four files:
@@ -1064,8 +1071,13 @@ The +views/comments/index.html.erb+ view:
     <td><%=h comment.commenter %></td>
     <td><%=h comment.body %></td>
     <td><%= link_to 'Show', post_comment_path(@post, comment) %></td>
-    <td><%= link_to 'Edit', edit_post_comment_path(@post, comment) %></td>
-    <td><%= link_to 'Destroy', post_comment_path(@post, comment), :confirm => 'Are you sure?', :method => :delete %></td>
+    <td>
+        <%= link_to 'Edit', edit_post_comment_path(@post, comment) %>
+    </td>
+    <td>
+        <%= link_to 'Destroy', post_comment_path(@post, comment), 
+            :confirm => 'Are you sure?', :method => :delete %>
+    </td>
   </tr>
 <% end %>
 </table>
-- 
cgit v1.2.3


From 7a1b62ef66d744daf972069f37480ff5ce599baa Mon Sep 17 00:00:00 2001
From: Bobby Wilson <bwilson@90octane.com>
Date: Mon, 9 Feb 2009 13:32:43 -0700
Subject: fixed a minor typo, needed an h in Neighborly

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 3163fdb4bc..6a600e801a 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -21,7 +21,7 @@ This guide is designed for beginners who want to get started with a Rails applic
 
 It is highly recommended that you *familiarize yourself with Ruby before diving into Rails*. You will find it much easier to follow what’s going on with a Rails application if you understand basic Ruby syntax. Rails isn’t going to magically revolutionize the way you write web applications if you have no experience with the language it uses. There are some good free resources on the internet for learning Ruby, including:
 
-* "Mr. Neigborly’s Humble Little Ruby Book":http://www.humblelittlerubybook.com
+* "Mr. Neighborly’s Humble Little Ruby Book":http://www.humblelittlerubybook.com
 * "Programming Ruby":http://www.rubycentral.com/book
 * "Why’s (Poignant) Guide to Ruby":http://poignantguide.net/ruby
 
-- 
cgit v1.2.3


From 74c8ff53e7fff1e7c1ceaf5f5205668dfa81557d Mon Sep 17 00:00:00 2001
From: Andreas Scherer <andreas_coder@freenet.de>
Date: Mon, 16 Feb 2009 11:47:23 +0100
Subject: More tables headers formatted.

---
 railties/guides/source/getting_started.textile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 6a600e801a..7c7f7e889c 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -163,7 +163,7 @@ $ cd blog
 
 In any case, Rails will create a folder in your working directory called <tt>blog</tt>. Open up that folder and explore its contents. Most of the work in this tutorial will happen in the <tt>app/</tt> folder, but here’s a basic rundown on the function of each folder that Rails creates in a new application by default:
 
-|File/Folder|Purpose|
+|_.File/Folder|_.Purpose|
 |README|This is a brief instruction manual for your application. Use it to tell others what your application does, how to set it up, and so on.|
 |Rakefile|This file contains batch jobs that can be run from the terminal.|
 |app/|Contains the controllers, models, and views for your application. You'll focus on this folder for the remainder of this guide.|
@@ -327,7 +327,7 @@ NOTE. While scaffolding will get you up and running quickly, the "one size fits
 
 The scaffold generator will build 14 files in your application, along with some folders, and edit one more. Here's a quick overview of what it creates:
 
-|File                                          |Purpose|
+|_.File                                        |_.Purpose|
 |app/models/post.rb                            |The Post model|
 |db/migrate/20090113124235_create_posts.rb     |Migration to create the posts table in your database (your name will include a different timestamp)|
 |app/views/posts/index.html.erb                |A view to display an index of all posts |
-- 
cgit v1.2.3


From 48791dda34530f1221c48740857173c267f677ca Mon Sep 17 00:00:00 2001
From: Andreas Scherer <andreas_coder@freenet.de>
Date: Tue, 17 Feb 2009 14:11:59 +0100
Subject: Remove empty line that breaks 'code' formatting.

---
 railties/guides/source/getting_started.textile | 1 -
 1 file changed, 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 7c7f7e889c..3d6c16f11c 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -387,7 +387,6 @@ To hook the posts up to the home page you've already created, you can add a link
 <code lang="ruby">
 <h1>Hello, Rails!</h1>
 <%= link_to "My Blog", posts_path %>
-
 </code>
 
 The +link_to+ method is one of Rails' built-in view helpers. It creates a hyperlink based on text to display and where to go - in this case, to the path for posts.
-- 
cgit v1.2.3


From 901df601fcf56923082dfe01c365ce27301eaff8 Mon Sep 17 00:00:00 2001
From: Mike Gunderloy <MikeG1@larkfarm.com>
Date: Mon, 2 Mar 2009 11:11:46 -0600
Subject: Added "Contributing" Guide

---
 railties/guides/source/getting_started.textile | 1 +
 1 file changed, 1 insertion(+)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 3d6c16f11c..6e02cfe1bd 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -115,6 +115,7 @@ If you’d like more details on REST as an architectural style, these resources
 * "A Brief Introduction to REST":http://www.infoq.com/articles/rest-introduction by Stefan Tilkov
 * "An Introduction to REST":http://bitworking.org/news/373/An-Introduction-to-REST (video tutorial) by Joe Gregorio
 * "Representational State Transfer":http://en.wikipedia.org/wiki/Representational_State_Transfer article in Wikipedia
+* "How to GET a Cup of Coffee":http://www.infoq.com/articles/webber-rest-workflow by Jim Webber, Savas Parastatidis & Ian Robinson
 
 h3. Creating a New Rails Project
 
-- 
cgit v1.2.3


From a4b1ccec5c1df24c8f9a18c599575e7263624ac4 Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Sun, 15 Mar 2009 21:31:20 +0100
Subject: revised links in guides according to W3C link checker report

---
 railties/guides/source/getting_started.textile | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 6e02cfe1bd..97f141b5e9 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -1,4 +1,4 @@
-h2. Getting Started With Rails
+h2. Getting Started with Rails
 
 This guide covers getting up and running with Ruby on Rails. After reading it, you should be familiar with:
 
@@ -23,7 +23,7 @@ It is highly recommended that you *familiarize yourself with Ruby before diving
 
 * "Mr. Neighborly’s Humble Little Ruby Book":http://www.humblelittlerubybook.com
 * "Programming Ruby":http://www.rubycentral.com/book
-* "Why’s (Poignant) Guide to Ruby":http://poignantguide.net/ruby
+* "Why’s (Poignant) Guide to Ruby":http://poignantguide.net/ruby/
 
 h3. What is Rails?
 
@@ -175,7 +175,7 @@ In any case, Rails will create a folder in your working directory called <tt>blo
 |log/|Application log files.|
 |public/|The only folder seen to the world as-is.  This is where your images, javascript, stylesheets (CSS), and other static files go.|
 |script/|Scripts provided by Rails to do recurring tasks, such as benchmarking, plugin installation, and starting the console or the web server.|
-|test/|Unit tests, fixtures, and other test apparatus. These are covered in "Testing Rails Applications":testing_rails_applications.html|
+|test/|Unit tests, fixtures, and other test apparatus. These are covered in "Testing Rails Applications":testing.html|
 |tmp/|Temporary files|
 |vendor/|A place for third-party code. In a typical Rails application, this includes Ruby Gems, the Rails source code (if you install it into your project) and plugins containing additional prepackaged functionality.|
 
@@ -310,7 +310,7 @@ This line illustrates one tiny bit of the "convention over configuration" approa
 
 Now if you navigate to +http://localhost:3000+ in your browser, you'll see the +home/index+ view.
 
-NOTE. For more information about routing, refer to "Rails Routing from the Outside In":routing_outside_in.html.
+NOTE. For more information about routing, refer to "Rails Routing from the Outside In":routing.html.
 
 h3. Getting Up and Running Quickly With Scaffolding
 
@@ -472,7 +472,7 @@ end
 
 This code sets the +@posts+ instance variable to an array of all posts in the database. +Post.find(:all)+ or +Post.all+ calls the +Post+ model to return all of the posts that are currently in the database, with no limiting conditions.
 
-TIP: For more information on finding records with Active Record, see "Active Record Finders":finders.html.
+TIP: For more information on finding records with Active Record, see "Active Record Query Interface":active_record_querying.html.
 
 The +respond_to+ block handles both HTML and XML calls to this action. If you browse to +http://localhost:3000/posts.xml+, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/view/posts/index.html.erb+:
 
@@ -846,7 +846,7 @@ end
 
 Rails runs _before filters_ before any action in the controller. You can use the +:only+ clause to limit a before filter to only certain actions, or an +:except+ clause to specifically skip a before filter for certain actions. Rails also allows you to define _after filters_ that run after processing an action, as well as _around filters_ that surround the processing of actions. Filters can also be defined in external classes to make it easy to share them between controllers.
 
-For more information on filters, see the "Action Controller Basics":actioncontroller_basics.html guide.
+For more information on filters, see the "Action Controller Overview":action_controller_overview.html guide.
 
 h3. Adding a Second Model
 
-- 
cgit v1.2.3


From c6ff88a4d272aa41aa74874456a3a8b6c7e488fb Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Mon, 30 Mar 2009 10:14:37 +0200
Subject: With -> with in a title

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 97f141b5e9..f0a43c09b7 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -312,7 +312,7 @@ Now if you navigate to +http://localhost:3000+ in your browser, you'll see the +
 
 NOTE. For more information about routing, refer to "Rails Routing from the Outside In":routing.html.
 
-h3. Getting Up and Running Quickly With Scaffolding
+h3. Getting Up and Running Quickly with Scaffolding
 
 Rails _scaffolding_ is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.
 
-- 
cgit v1.2.3


From c910c45b9d70d13b4e1e9c81d88dcd935fa4873b Mon Sep 17 00:00:00 2001
From: Nathan Lloyd Smith <nlloyds@gmail.com>
Date: Fri, 3 Apr 2009 13:44:09 -0500
Subject: Typo fix

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index f0a43c09b7..a216201490 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -474,7 +474,7 @@ This code sets the +@posts+ instance variable to an array of all posts in the da
 
 TIP: For more information on finding records with Active Record, see "Active Record Query Interface":active_record_querying.html.
 
-The +respond_to+ block handles both HTML and XML calls to this action. If you browse to +http://localhost:3000/posts.xml+, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/view/posts/index.html.erb+:
+The +respond_to+ block handles both HTML and XML calls to this action. If you browse to +http://localhost:3000/posts.xml+, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/views/posts/index.html.erb+:
 
 <erb>
 <h1>Listing posts</h1>
-- 
cgit v1.2.3


From dda04f700e5d4fe7b40194555f2edbf55c02bd8c Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Sun, 5 Apr 2009 11:48:01 +0200
Subject: fixes spelling of "JavaScript" and link to the complex form examples
 app

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index a216201490..7c029762a3 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -1269,7 +1269,7 @@ You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
 
 With these changes in place, you'll find that you can edit a post and its tags directly on the same view.
 
-NOTE. You may want to use javascript to dynamically add additional tags on a single form. For an example of this and other advanced techniques, see the "nested model sample application":http://github.com/alloy/complex-form-examples/tree/nested_attributes.
+NOTE. You may want to use JavaScript to dynamically add additional tags on a single form. For an example of this and other advanced techniques, see the "complex form examples application":http://github.com/alloy/complex-form-examples/tree/master.
 
 h3. What's Next?
 
-- 
cgit v1.2.3


From 1703fbbcef454eb9e63106c929ed90f4988fd43b Mon Sep 17 00:00:00 2001
From: Dana Jones <dana@sterlingrosedesign.com>
Date: Sat, 25 Apr 2009 01:33:48 -0500
Subject: Minor changes to scaffold code, addition of dependent destroy
 example.

---
 railties/guides/source/getting_started.textile | 42 +++++++++++++++++---------
 1 file changed, 28 insertions(+), 14 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 7c029762a3..9222c9f7ad 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -87,7 +87,7 @@ Action Mailer is a framework for building e-mail services. You can use Action Ma
 
 h5. Active Resource
 
-Active Resource provides a framework for managing the connection between business objects an RESTful web services. It implements a way to map web-based resources to local objects with CRUD semantics.
+Active Resource provides a framework for managing the connection between business objects and RESTful web services. It implements a way to map web-based resources to local objects with CRUD semantics.
 
 h5. Railties
 
@@ -461,7 +461,7 @@ The easiest place to start looking at functionality is with the code that lists
 
 <ruby>
 def index
-  @posts = Post.find(:all)
+  @posts = Post.all
 
   respond_to do |format|
     format.html # index.html.erb
@@ -486,7 +486,7 @@ The +respond_to+ block handles both HTML and XML calls to this action. If you br
     <th>Content</th>
   </tr>
 
-<% for post in @posts %>
+<% @posts.each do |post| %>
   <tr>
     <td><%=h post.name %></td>
     <td><%=h post.title %></td>
@@ -582,7 +582,7 @@ The +new.html.erb+ view displays this empty Post to the user:
 <%= link_to 'Back', posts_path %>
 </erb>
 
-The +form_for+ block is used to create an HTML form. Within this block, you have access to methods to build various controls on the form. For example, +f.text_field :name+ tells Rails to create a text input on the form, and to hook it up to the +name+ attribute of the instance being displayed. You can only use these methods with attributes of the model that the form is based on (in this case +name+, +title+, and +content+). Rails uses +form_for+ in preference to having your write raw HTML because the code is more succinct, and because it explicitly ties the form to a particular model instance.
+The +form_for+ block is used to create an HTML form. Within this block, you have access to methods to build various controls on the form. For example, +f.text_field :name+ tells Rails to create a text input on the form, and to hook it up to the +name+ attribute of the instance being displayed. You can only use these methods with attributes of the model that the form is based on (in this case +name+, +title+, and +content+). Rails uses +form_for+ in preference to having you write raw HTML because the code is more succinct, and because it explicitly ties the form to a particular model instance.
 
 TIP: If you need to create an HTML form that displays arbitrary fields, not tied to a model, you should use the +form_tag+ method, which provides shortcuts for building forms that are not necessarily tied to a model instance.
 
@@ -609,7 +609,7 @@ end
 
 The +create+ action instantiates a new Post object from the data supplied by the user on the form, which Rails makes available in the +params+ hash. After saving the new post, it uses +flash[:notice]+ to create an informational message for the user, and redirects to the show action for the post. If there's any problem, the +create+ action just shows the +new+ view a second time, with any error messages.
 
-Rails provides the +flash+ hash (usually just called the Flash) so that messages can be carried over to another action, providing the user with useful information on the status of their request.  In the case of +create+, the user never actually sees any page rendered during the Post creation process, because it immediately redirects to the new Post as soon Rails saves the record. The Flash carries over a message to the next action, so that when the user is redirected back to the +show+ action, they are presented with a message saying "Post was successfully created."
+Rails provides the +flash+ hash (usually just called the Flash) so that messages can be carried over to another action, providing the user with useful information on the status of their request. In the case of +create+, the user never actually sees any page rendered during the Post creation process, because it immediately redirects to the new Post as soon Rails saves the record. The Flash carries over a message to the next action, so that when the user is redirected back to the +show+ action, they are presented with a message saying "Post was successfully created."
 
 h4. Showing an Individual Post
 
@@ -785,7 +785,7 @@ As you saw earlier, the scaffold-generated views for the +new+ and +edit+ action
 
 Now, when Rails renders the +new+ or +edit+ view, it will insert the +_form+ partial at the indicated point. Note the naming convention for partials: if you refer to a partial named +form+ inside of a view, the corresponding file is +_form.html.erb+, with a leading underscore.
 
-For more information on partials, refer to the "Layouts and Rending in Rails":layouts_and_rendering.html guide.
+For more information on partials, refer to the "Layouts and Rendering in Rails":layouts_and_rendering.html#using-partials guide.
 
 h4. Using Filters to Eliminate Controller Duplication
 
@@ -954,7 +954,7 @@ With the model in hand, you can turn your attention to creating a matching contr
 $ script/generate controller Comments index show new edit
 </shell>
 
-This creates seven files:
+This creates eight files:
 
 * +app/controllers/comments_controller.rb+ - The controller
 * +app/helpers/comments_helper.rb+ - A view helper file
@@ -963,6 +963,7 @@ This creates seven files:
 * +app/views/comments/new.html.erb+ - The view for the new action
 * +app/views/comments/edit.html.erb+ - The view for the edit action
 * +test/functional/comments_controller_test.rb+ - The functional tests for the controller
+* +test/unit/helpers/comments_helper_test.rb+ - The unit tests for the helper
 
 The controller will be generated with empty methods and views for each action that you specified in the call to +script/generate controller+:
 
@@ -1031,11 +1032,7 @@ class CommentsController < ApplicationController
     @post = Post.find(params[:post_id])
     @comment = Comment.find(params[:id])
     @comment.destroy
-
-    respond_to do |format|
-      format.html { redirect_to post_comments_path(@post) }
-      format.xml  { head :ok }
-    end
+    redirect_to post_comments_path(@post)
   end
 
 end
@@ -1198,6 +1195,22 @@ As a next step, I'll modify the +views/posts/show.html.erb+ view to show the com
 
 Note that each post has its own individual comments collection, accessible as +@post.comments+. That's a consequence of the declarative associations in the models. Path helpers such as +post_comments_path+ come from the nested route declaration in +config/routes.rb+.
 
+h4. Deleting Associated Objects
+
+If you decide at some point to delete a post, you likely want to delete the comments associated with that post as well. You can do so by taking advantage of the association option +dependent+. All you need to do is modify the +post.rb+ as follows:
+
+<ruby>
+class Post < ActiveRecord::Base
+  validates_presence_of :name, :title
+  validates_length_of :title, :minimum => 5
+  has_many :comments, :dependent => :destroy
+  has_many :tags
+
+  accepts_nested_attributes_for :tags, :allow_destroy => :true, 
+    :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }
+end
+</ruby> 
+
 h3. Building a Multi-Model Form
 
 Comments and posts are edited on two separate forms - which makes sense, given the flow of this mini-application. But what if you want to edit more than one thing on a single form? Rails 2.3 offers new support for nested forms. Let's add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
@@ -1221,7 +1234,7 @@ class Post < ActiveRecord::Base
   has_many :comments
   has_many :tags
 
-  accepts_nested_attributes_for :tags, :allow_destroy => :true  ,
+  accepts_nested_attributes_for :tags, :allow_destroy => :true,
     :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }
 end
 </ruby>
@@ -1240,7 +1253,7 @@ You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
     <%= post_form.text_field :name %>
   </p>
   <p>
-    <%= post_form.label :title, "title" %><br />
+    <%= post_form.label :title, "Title" %><br />
     <%= post_form.text_field :title %>
   </p>
   <p>
@@ -1278,6 +1291,7 @@ Now that you've seen your first Rails application, you should feel free to updat
 * The "Ruby On Rails guides":http://guides.rubyonrails.org
 * The "Ruby on Rails mailing list":http://groups.google.com/group/rubyonrails-talk
 * The #rubyonrails channel on irc.freenode.net
+* The "Rails Wiki":http://wiki.rubyonrails.org/
 
 Rails also comes with built-in help that you can generate using the rake command-line utility:
 
-- 
cgit v1.2.3


From 26ad104e72e2b758815a043341dd83a1b02e8c7f Mon Sep 17 00:00:00 2001
From: Andreas Scherer <andreas_coder@freenet.de>
Date: Thu, 14 May 2009 14:35:18 +0200
Subject: 'TIP.' replaced with 'TIP:' for consistent formatting.

---
 railties/guides/source/getting_started.textile | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 9222c9f7ad..c15d6aa8ab 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -154,7 +154,7 @@ And if you’re using PostgreSQL for data storage, run this command:
 $ rails blog -d postgresql
 </shell>
 
-TIP. You can see all of the switches that the Rails application builder accepts by running <tt>rails -h</tt>.
+TIP: You can see all of the switches that the Rails application builder accepts by running <tt>rails -h</tt>.
 
 After you create the blog application, switch to its folder to continue work directly in that application:
 
@@ -259,7 +259,7 @@ One of the traditional places to start with a new language is by getting some te
 $ script/generate controller home index
 </shell>
 
-TIP. If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
+TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
 
 Rails will create several files for you, including +app/views/home/index.html.erb+. This is the template that will be used to display the results of the +index+ action (method) in the +home+ controller. Open this file in your text editor and edit it to contain a single line of code:
 
@@ -279,7 +279,7 @@ This will fire up an instance of the Mongrel web server by default (Rails can al
 
 !images/rails_welcome.png(Welcome Aboard screenshot)!
 
-TIP. To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to stop the server; changes you make in files will be automatically picked up by the server.
+TIP: To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to stop the server; changes you make in files will be automatically picked up by the server.
 
 The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page. To view the page you just created, navigate to +http://localhost:3000/home/index+.
 
@@ -400,7 +400,7 @@ Now you're ready to start working with posts. To do that, navigate to +http://lo
 
 This is the result of Rails rendering the +index+ view of your posts. There aren't currently any posts in the database, but if you click the +New Post+ link you can create one. After that, you'll find that you can edit posts, look at their details, or destroy them. All of the logic and HTML to handle this was built by the single +script/generate scaffold+ command.
 
-TIP. In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server.
+TIP: In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server.
 
 Congratulations, you're riding the rails! Now it's time to see how it all works.
 
@@ -510,7 +510,7 @@ This view iterates over the contents of the +@posts+ array to display content an
 * +link_to+ builds a hyperlink to a particular destination
 * +edit_post_path+ is a helper that Rails provides as part of RESTful routing. You’ll see a variety of these helpers for the different actions that the controller includes.
 
-TIP. For more details on the rendering process, see "Layouts and Rendering in Rails":layouts_and_rendering.html.
+TIP: For more details on the rendering process, see "Layouts and Rendering in Rails":layouts_and_rendering.html.
 
 h4. Customizing the Layout
 
-- 
cgit v1.2.3


From 72b033f6b6ba590a3993d72fef615548d3a8b7f7 Mon Sep 17 00:00:00 2001
From: Joseph Pecoraro <joepeck02@gmail.com>
Date: Fri, 29 May 2009 10:29:44 -0400
Subject: Corrected paths to standard.

---
 railties/guides/source/getting_started.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index c15d6aa8ab..15f900563f 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -383,7 +383,7 @@ NOTE: Because you're working in the development environment by default, this com
 
 h4. Adding a Link
 
-To hook the posts up to the home page you've already created, you can add a link to the home page. Open +/app/views/home/index.html.erb+ and modify it as follows:
+To hook the posts up to the home page you've already created, you can add a link to the home page. Open +app/views/home/index.html.erb+ and modify it as follows:
 
 <code lang="ruby">
 <h1>Hello, Rails!</h1>
@@ -1295,8 +1295,8 @@ Now that you've seen your first Rails application, you should feel free to updat
 
 Rails also comes with built-in help that you can generate using the rake command-line utility:
 
-* Running +rake doc:guides+ will put a full copy of the Rails Guides in the +/doc/guides+ folder of your application. Open +/doc/guides/index.html+ in your web browser to explore the Guides.
-* Running +rake doc:rails+ will put a full copy of the API documentation for Rails in the +/doc/api+ folder of your application. Open +/doc/api/index.html+ in your web browser to explore the API documentation.
+* Running +rake doc:guides+ will put a full copy of the Rails Guides in the +doc/guides+ folder of your application. Open +doc/guides/index.html+ in your web browser to explore the Guides.
+* Running +rake doc:rails+ will put a full copy of the API documentation for Rails in the +doc/api+ folder of your application. Open +doc/api/index.html+ in your web browser to explore the API documentation.
 
 h3. Changelog
 
-- 
cgit v1.2.3


From f68fca2e7665dec8efcc1f45477760ef266d3d43 Mon Sep 17 00:00:00 2001
From: Joseph Pecoraro <joepeck02@gmail.com>
Date: Fri, 29 May 2009 16:27:50 -0400
Subject: Linked to the IRC channel.

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 15f900563f..6c7389b62d 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -1290,7 +1290,7 @@ Now that you've seen your first Rails application, you should feel free to updat
 
 * The "Ruby On Rails guides":http://guides.rubyonrails.org
 * The "Ruby on Rails mailing list":http://groups.google.com/group/rubyonrails-talk
-* The #rubyonrails channel on irc.freenode.net
+* The "#rubyonrails":irc://irc.freenode.net/#rubyonrails channel on irc.freenode.net
 * The "Rails Wiki":http://wiki.rubyonrails.org/
 
 Rails also comes with built-in help that you can generate using the rake command-line utility:
-- 
cgit v1.2.3


From 8e06b2ce256a8ac62aab0f085b4c9e46063b339c Mon Sep 17 00:00:00 2001
From: Joseph Pecoraro <joepeck02@gmail.com>
Date: Sat, 30 May 2009 01:16:03 -0400
Subject: Fixed some links pointing to guides.rails.info to relative links.
 Fixed hashs as well.

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 6c7389b62d..1ab271683f 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -944,7 +944,7 @@ map.resources :posts, :has_many => :comments
 
 This creates +comments+ as a _nested resource_ within +posts+. This is another part of capturing the hierarchical relationship that exists between posts and comments.
 
-TIP: For more information on routing, see the "Rails Routing from the Outside In":routing_outside_in.html guide.
+TIP: For more information on routing, see the "Rails Routing from the Outside In":routing.html guide.
 
 h4. Generating a Controller
 
-- 
cgit v1.2.3


From 1c167cd6fb08c78e3b16d6a8e73a131412db70a8 Mon Sep 17 00:00:00 2001
From: Mike Gunderloy <MikeG1@larkfarm.com>
Date: Sat, 18 Jul 2009 16:50:52 -0500
Subject: Minor cleanup to Getting Started for 2.3.3

---
 railties/guides/source/getting_started.textile | 77 +++++++++++++-------------
 1 file changed, 38 insertions(+), 39 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 1ab271683f..5c05648f12 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -9,7 +9,7 @@ This guide covers getting up and running with Ruby on Rails. After reading it, y
 
 endprologue.
 
-WARNING. This Guide is based on Rails 2.3. Some of the code shown here will not work in older versions of Rails.
+WARNING. This Guide is based on Rails 2.3.3. Some of the code shown here will not work in other versions of Rails.
 
 h3. This Guide Assumes
 
@@ -19,22 +19,22 @@ This guide is designed for beginners who want to get started with a Rails applic
 * The "RubyGems":http://rubyforge.org/frs/?group_id=126 packaging system
 * A working installation of "SQLite":http://www.sqlite.org (preferred), "MySQL":http://www.mysql.com, or "PostgreSQL":http://www.postgresql.org
 
-It is highly recommended that you *familiarize yourself with Ruby before diving into Rails*. You will find it much easier to follow what’s going on with a Rails application if you understand basic Ruby syntax. Rails isn’t going to magically revolutionize the way you write web applications if you have no experience with the language it uses. There are some good free resources on the internet for learning Ruby, including:
+It is highly recommended that you *familiarize yourself with Ruby before diving into Rails*. You will find it much easier to follow what's going on with a Rails application if you understand basic Ruby syntax. Rails isn't going to magically revolutionize the way you write web applications if you have no experience with the language it uses. There are some good free resources on the internet for learning Ruby, including:
 
-* "Mr. Neighborly’s Humble Little Ruby Book":http://www.humblelittlerubybook.com
+* "Mr. Neighborly's Humble Little Ruby Book":http://www.humblelittlerubybook.com
 * "Programming Ruby":http://www.rubycentral.com/book
-* "Why’s (Poignant) Guide to Ruby":http://poignantguide.net/ruby/
+* "Why's (Poignant) Guide to Ruby":http://poignantguide.net/ruby/
 
 h3. What is Rails?
 
-Rails is a web development framework written in the Ruby language. It is designed to make programming web applications easier by making several assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Longtime Rails developers also report that it makes web application development more fun.
+Rails is a web development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Longtime Rails developers also report that it makes web application development more fun.
 
-Rails is opinionated software. That is, it assumes that there is a best way to do things, and it’s designed to encourage that best way - and in some cases to discourage alternatives. If you learn "The Rails Way" you’ll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.
+Rails is opinionated software. That is, it assumes that there is a best way to do things, and it's designed to encourage that best way - and in some cases to discourage alternatives. If you learn "The Rails Way" you'll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.
 
 The Rails philosophy includes several guiding principles:
 
-* DRY - "Don’t Repeat Yourself" - suggests that writing the same code over and over again is a bad thing.
-* Convention Over Configuration - means that Rails makes assumptions about what you want to do and how you’re going to do it, rather than letting you tweak every little thing through endless configuration files.
+* DRY - "Don't Repeat Yourself" - suggests that writing the same code over and over again is a bad thing.
+* Convention Over Configuration - means that Rails makes assumptions about what you want to do and how you're going to do it, rather than letting you tweak every little thing through endless configuration files.
 * REST is the best pattern for web applications - organizing your application around resources and standard HTTP verbs is the fastest way to go.
 
 h4. The MVC Architecture
@@ -47,7 +47,7 @@ Rails is organized around the Model, View, Controller architecture, usually just
 
 h5. Models
 
-A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, one table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.
+A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, one table in your database will correspond to one model in your application. The bulk of your application's business logic will be concentrated in the models.
 
 h5. Views
 
@@ -99,7 +99,7 @@ Active Support is an extensive collection of utility classes and standard Ruby l
 
 h4. REST
 
-The foundation of the RESTful architecture is generally considered to be Roy Fielding’s doctoral thesis, "Architectural Styles and the Design of Network-based Software Architectures":http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Fortunately, you need not read this entire document to understand how REST works in Rails. REST, an acronym for Representational State Transfer, boils down to two main principles for our purposes:
+The foundation of the RESTful architecture is generally considered to be Roy Fielding's doctoral thesis, "Architectural Styles and the Design of Network-based Software Architectures":http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Fortunately, you need not read this entire document to understand how REST works in Rails. REST, an acronym for Representational State Transfer, boils down to two main principles for our purposes:
 
 * Using resource identifiers (which, for the purposes of discussion, you can think of as URLs) to represent resources
 * Transferring representations of the state of that resource between system components.
@@ -110,7 +110,7 @@ For example, to a Rails application a request such as this:
 
 would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities and browser quirks.
 
-If you’d like more details on REST as an architectural style, these resources are more approachable than Fielding’s thesis:
+If you'd like more details on REST as an architectural style, these resources are more approachable than Fielding's thesis:
 
 * "A Brief Introduction to REST":http://www.infoq.com/articles/rest-introduction by Stefan Tilkov
 * "An Introduction to REST":http://bitworking.org/news/373/An-Introduction-to-REST (video tutorial) by Joe Gregorio
@@ -119,7 +119,7 @@ If you’d like more details on REST as an architectural style, these resources
 
 h3. Creating a New Rails Project
 
-If you follow this guide, you’ll create a Rails project called <tt>blog</tt>, a (very) simple weblog. Before you can start building the application, you need to make sure that you have Rails itself installed.
+If you follow this guide, you'll create a Rails project called <tt>blog</tt>, a (very) simple weblog. Before you can start building the application, you need to make sure that you have Rails itself installed.
 
 h4. Installing Rails
 
@@ -131,8 +131,10 @@ $ gem install rails
 
 NOTE. There are some special circumstances in which you might want to use an alternate installation strategy:
 
-* If you’re working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
-* If you want to keep up with cutting-edge changes to Rails, you’ll want to clone the "Rails source code":http://github.com/rails/rails/tree/master from github. This is not recommended as an option for beginners, though.
+* If you're working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
+* If you want to keep up with cutting-edge changes to Rails, you'll want to clone the "Rails source code":http://github.com/rails/rails/tree/master from github. This is not recommended as an option for beginners, though.
+
+WARNING. As of mid-2009, cloning the master branch will get you preliminary Rails 3.0 code. To follow along with this guide, you should clone the 2-3-stable branch instead.
 
 h4. Creating the Blog Application
 
@@ -148,7 +150,7 @@ This will create a Rails application that uses a SQLite database for data storag
 $ rails blog -d mysql
 </shell>
 
-And if you’re using PostgreSQL for data storage, run this command:
+And if you're using PostgreSQL for data storage, run this command:
 
 <shell>
 $ rails blog -d postgresql
@@ -162,7 +164,7 @@ After you create the blog application, switch to its folder to continue work dir
 $ cd blog
 </shell>
 
-In any case, Rails will create a folder in your working directory called <tt>blog</tt>. Open up that folder and explore its contents. Most of the work in this tutorial will happen in the <tt>app/</tt> folder, but here’s a basic rundown on the function of each folder that Rails creates in a new application by default:
+In any case, Rails will create a folder in your working directory called <tt>blog</tt>. Open up that folder and explore its contents. Most of the work in this tutorial will happen in the <tt>app/</tt> folder, but here's a basic rundown on the function of each folder that Rails creates in a new application by default:
 
 |_.File/Folder|_.Purpose|
 |README|This is a brief instruction manual for your application. Use it to tell others what your application does, how to set it up, and so on.|
@@ -508,7 +510,7 @@ This view iterates over the contents of the +@posts+ array to display content an
 
 * +h+ is a Rails helper method to sanitize displayed data, preventing cross-site scripting attacks
 * +link_to+ builds a hyperlink to a particular destination
-* +edit_post_path+ is a helper that Rails provides as part of RESTful routing. You’ll see a variety of these helpers for the different actions that the controller includes.
+* +edit_post_path+ is a helper that Rails provides as part of RESTful routing. You'll see a variety of these helpers for the different actions that the controller includes.
 
 TIP: For more details on the rendering process, see "Layouts and Rendering in Rails":layouts_and_rendering.html.
 
@@ -710,7 +712,7 @@ end
 
 In the +update+ action, Rails first uses the +:id+ parameter passed back from the edit view to locate the database record that's being edited. The +update_attributes+ call then takes the rest of the parameters from the request and applies them to this record. If all goes well, the user is redirected to the post's +show+ view. If there are any problems, it's back to +edit+ to correct them.
 
-NOTE. Sharp-eyed readers will have noticed that the +form_for+ declaration is identical for the +new+ and +edit+ views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a _partial template_, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that’s easy to modify if you want different forms for +create+ and +edit+.
+NOTE. Sharp-eyed readers will have noticed that the +form_for+ declaration is identical for the +new+ and +edit+ views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a _partial template_, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that's easy to modify if you want different forms for +create+ and +edit+.
 
 h4. Destroying a Post
 
@@ -732,7 +734,7 @@ The +destroy+ method of an Active Record model instance removes the correspondin
 
 h3. DRYing up the Code
 
-At this point, it’s worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views and _filters_ to help with duplication in controllers.
+At this point, it's worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views and _filters_ to help with duplication in controllers.
 
 h4. Using Partials to Eliminate View Duplication
 
@@ -740,13 +742,13 @@ As you saw earlier, the scaffold-generated views for the +new+ and +edit+ action
 
 <tt>new.html.erb</tt>:
 
-<html>
+<erb>
 <h1>New post</h1>
 
 <%= render :partial => "form" %>
 
 <%= link_to 'Back', posts_path %>
-</html>
+</erb>
 
 <tt>edit.html.erb</tt>:
 
@@ -789,7 +791,7 @@ For more information on partials, refer to the "Layouts and Rendering in Rails":
 
 h4. Using Filters to Eliminate Controller Duplication
 
-At this point, if you look at the controller for posts, you’ll see some duplication:
+At this point, if you look at the controller for posts, you'll see some duplication:
 
 <ruby>
 class PostsController < ApplicationController
@@ -815,7 +817,7 @@ class PostsController < ApplicationController
 end
 </ruby>
 
-Four instances of the exact same line of code doesn’t seem very DRY. Rails provides _filters_ as a way to address this sort of repeated code. In this case, you can DRY things up by using a +before_filter+:
+Four instances of the exact same line of code doesn't seem very DRY. Rails provides _filters_ as a way to address this sort of repeated code. In this case, you can DRY things up by using a +before_filter+:
 
 <ruby>
 class PostsController < ApplicationController
@@ -837,10 +839,10 @@ class PostsController < ApplicationController
     # ...
   end
 
-  private
-    def find_post
-      @post = Post.find(params[:id])
-    end
+private
+  def find_post
+    @post = Post.find(params[:id])
+  end
 end
 </ruby>
 
@@ -988,23 +990,21 @@ You'll need to flesh this out with code to actually process requests appropriate
 
 <ruby>
 class CommentsController < ApplicationController
+  before_filter :find_post
+
   def index
-    @post = Post.find(params[:post_id])
     @comments = @post.comments
   end
 
   def show
-    @post = Post.find(params[:post_id])
     @comment = @post.comments.find(params[:id])
   end
 
   def new
-    @post = Post.find(params[:post_id])
     @comment = @post.comments.build
   end
 
   def create
-    @post = Post.find(params[:post_id])
     @comment = @post.comments.build(params[:comment])
     if @comment.save
       redirect_to post_comment_url(@post, @comment)
@@ -1014,12 +1014,10 @@ class CommentsController < ApplicationController
   end
 
   def edit
-    @post = Post.find(params[:post_id])
     @comment = @post.comments.find(params[:id])
   end
 
   def update
-    @post = Post.find(params[:post_id])
     @comment = Comment.find(params[:id])
     if @comment.update_attributes(params[:comment])
       redirect_to post_comment_url(@post, @comment)
@@ -1029,12 +1027,16 @@ class CommentsController < ApplicationController
   end
 
   def destroy
-    @post = Post.find(params[:post_id])
     @comment = Comment.find(params[:id])
     @comment.destroy
     redirect_to post_comments_path(@post)
   end
 
+private
+  def find_post
+    @post = Post.find(params[:post_id])
+  end
+
 end
 </ruby>
 
@@ -1204,10 +1206,6 @@ class Post < ActiveRecord::Base
   validates_presence_of :name, :title
   validates_length_of :title, :minimum => 5
   has_many :comments, :dependent => :destroy
-  has_many :tags
-
-  accepts_nested_attributes_for :tags, :allow_destroy => :true, 
-    :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }
 end
 </ruby> 
 
@@ -1225,7 +1223,7 @@ Run the migration to create the database table:
 $ rake db:migrate
 </shell>
 
-Next, edit the +post.rb+ file to create the other side of the association, and to tell Rails that you intend to edit tags via posts:
+Next, edit the +post.rb+ file to create the other side of the association, and to tell Rails (via the +accepts_nested_attributes+ macro) that you intend to edit tags via posts:
 
 <ruby>
 class Post < ActiveRecord::Base
@@ -1302,6 +1300,7 @@ h3. Changelog
 
 "Lighthouse ticket":http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2
 
+* July 18, 2009: Minor cleanup in anticipation of Rails 2.3.3 by "Mike Gunderloy":credits.html#mgunderloy
 * February 1, 2009: Updated for Rails 2.3 by "Mike Gunderloy":credits.html#mgunderloy
 * November 3, 2008: Formatting patch from Dave Rothlisberger
 * November 1, 2008: First approved version by "Mike Gunderloy":credits.html#mgunderloy
-- 
cgit v1.2.3


From ea6cc2800fa82ac643e5028f285c84427b901829 Mon Sep 17 00:00:00 2001
From: kitallis <kitallis@gmail.com>
Date: Sat, 29 Aug 2009 09:18:53 -0700
Subject: two typos fixed

---
 railties/guides/source/getting_started.textile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 5c05648f12..eef221266e 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -51,7 +51,7 @@ A model represents the information (data) of the application and the rules to ma
 
 h5. Views
 
-Views represent the user interface of your application. In Rails, views are often HTML files with embedded Ruby code that performs tasks related solely to the presentation of the data. Views handle the job of providing data to the web browser or other tool that is used to make requests from your application.
+Views represent the user interface of your application. In Rails, views are often HTML files with embedded Ruby code that perform tasks related solely to the presentation of the data. Views handle the job of providing data to the web browser or other tool that is used to make requests from your application.
 
 h5. Controllers
 
@@ -1052,7 +1052,7 @@ This creates a new +Comment+ object _and_ sets up the +post_id+ field to have th
 
 h4. Building Views
 
-Because you skipped scaffolding, you'll need to build views for comments "by hand." Invoking +script/generate controller+ will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.
+Because you skipped scaffolding, you'll need to build views for comments "by hand". Invoking +script/generate controller+ will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.
 
 The +views/comments/index.html.erb+ view:
 
-- 
cgit v1.2.3


From 4dccf18b93e568cca8638ab3ad6f47a0275d2a05 Mon Sep 17 00:00:00 2001
From: Luigi Montanez <luigi.montanez@gmail.com>
Date: Fri, 4 Sep 2009 11:42:07 -0400
Subject: Link to the mislav-hosted Why's Poignant Guide.

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index eef221266e..8abc9d2a47 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -23,7 +23,7 @@ It is highly recommended that you *familiarize yourself with Ruby before diving
 
 * "Mr. Neighborly's Humble Little Ruby Book":http://www.humblelittlerubybook.com
 * "Programming Ruby":http://www.rubycentral.com/book
-* "Why's (Poignant) Guide to Ruby":http://poignantguide.net/ruby/
+* "Why's (Poignant) Guide to Ruby":http://mislav.uniqpath.com/poignant-guide/
 
 h3. What is Rails?
 
-- 
cgit v1.2.3


From 106b78d2efb39d8ea347e141eced61b70ca52618 Mon Sep 17 00:00:00 2001
From: mazuhl <max.mitchell@gmail.com>
Date: Sun, 1 Nov 2009 21:48:54 +0800
Subject: Swapped : for . on a NOTE section.

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 8abc9d2a47..9a87d28d18 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -381,7 +381,7 @@ $ rake db:migrate
 
 Remember, you can't run migrations before running +rake db:create+ to create your database, as we covered earlier.
 
-NOTE: Because you're working in the development environment by default, this command will apply to the database defined in the +development+ section of your +config/database.yml+ file.
+NOTE. Because you're working in the development environment by default, this command will apply to the database defined in the +development+ section of your +config/database.yml+ file.
 
 h4. Adding a Link
 
-- 
cgit v1.2.3


From bf7ec2d7457f9b0b16c62ce2157721c1213aa3c5 Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Wed, 30 Dec 2009 00:22:36 +0100
Subject: fixes link to Pickaxe in getting started guide

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 9a87d28d18..bd6dbda199 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -22,7 +22,7 @@ This guide is designed for beginners who want to get started with a Rails applic
 It is highly recommended that you *familiarize yourself with Ruby before diving into Rails*. You will find it much easier to follow what's going on with a Rails application if you understand basic Ruby syntax. Rails isn't going to magically revolutionize the way you write web applications if you have no experience with the language it uses. There are some good free resources on the internet for learning Ruby, including:
 
 * "Mr. Neighborly's Humble Little Ruby Book":http://www.humblelittlerubybook.com
-* "Programming Ruby":http://www.rubycentral.com/book
+* "Programming Ruby":http://www.ruby-doc.org/docs/ProgrammingRuby/
 * "Why's (Poignant) Guide to Ruby":http://mislav.uniqpath.com/poignant-guide/
 
 h3. What is Rails?
-- 
cgit v1.2.3


From 6b2ee4e8a049aa46aca39228e804c0fd4ffc57b4 Mon Sep 17 00:00:00 2001
From: Mikel Lindsaar <raasdnil@gmail.com>
Date: Sun, 24 Jan 2010 15:55:29 +1100
Subject: Updated "Getting Started" to work and reflect changes in Rails 3.0

Also created http://github.com/mikel/getting-started-code which is
a copy of all the code in this guide.
---
 railties/guides/source/getting_started.textile | 486 ++++++++++++-------------
 1 file changed, 233 insertions(+), 253 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index bd6dbda199..4d406c09da 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -9,13 +9,13 @@ This guide covers getting up and running with Ruby on Rails. After reading it, y
 
 endprologue.
 
-WARNING. This Guide is based on Rails 2.3.3. Some of the code shown here will not work in other versions of Rails.
+WARNING. This Guide is based on Rails 3.0. Some of the code shown here will not work in other versions of Rails.
 
 h3. This Guide Assumes
 
 This guide is designed for beginners who want to get started with a Rails application from scratch. It does not assume that you have any prior experience with Rails. However, to get the most out of it, you need to have some prerequisites installed:
 
-* The "Ruby":http://www.ruby-lang.org/en/downloads language
+* The "Ruby":http://www.ruby-lang.org/en/downloads language version 1.8.7 or higher
 * The "RubyGems":http://rubyforge.org/frs/?group_id=126 packaging system
 * A working installation of "SQLite":http://www.sqlite.org (preferred), "MySQL":http://www.mysql.com, or "PostgreSQL":http://www.postgresql.org
 
@@ -91,7 +91,7 @@ Active Resource provides a framework for managing the connection between busines
 
 h5. Railties
 
-Railties is the core Rails code that builds new Rails applications and glues the various frameworks together in any Rails application.
+Railties is the core Rails code that builds new Rails applications and glues the various frameworks and plugins together in any Rails application.
 
 h5. Active Support
 
@@ -134,8 +134,6 @@ NOTE. There are some special circumstances in which you might want to use an alt
 * If you're working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
 * If you want to keep up with cutting-edge changes to Rails, you'll want to clone the "Rails source code":http://github.com/rails/rails/tree/master from github. This is not recommended as an option for beginners, though.
 
-WARNING. As of mid-2009, cloning the master branch will get you preliminary Rails 3.0 code. To follow along with this guide, you should clone the 2-3-stable branch instead.
-
 h4. Creating the Blog Application
 
 Open a terminal, navigate to a folder where you have rights to create files, and type:
@@ -167,10 +165,13 @@ $ cd blog
 In any case, Rails will create a folder in your working directory called <tt>blog</tt>. Open up that folder and explore its contents. Most of the work in this tutorial will happen in the <tt>app/</tt> folder, but here's a basic rundown on the function of each folder that Rails creates in a new application by default:
 
 |_.File/Folder|_.Purpose|
-|README|This is a brief instruction manual for your application. Use it to tell others what your application does, how to set it up, and so on.|
+|Gemfile|This file allows you to specify what gem dependencies are needed for your Rails application.|
+|README.rdoc|This is a brief instruction manual for your application. Use it to tell others what your application does, how to set it up, and so on.|
 |Rakefile|This file contains batch jobs that can be run from the terminal.|
 |app/|Contains the controllers, models, and views for your application. You'll focus on this folder for the remainder of this guide.|
+|bin/|Holds various executables needed for your Rails application.|
 |config/|Configure your application's runtime rules, routes, database, and more.|
+|config.ru|Rack configuration for Rack based servers used to start the application.|
 |db/|Shows your current database schema, as well as the database migrations. You'll learn about migrations shortly.|
 |doc/|In-depth documentation for your application.|
 |lib/|Extended modules for your application (not covered in this guide).|
@@ -179,7 +180,18 @@ In any case, Rails will create a folder in your working directory called <tt>blo
 |script/|Scripts provided by Rails to do recurring tasks, such as benchmarking, plugin installation, and starting the console or the web server.|
 |test/|Unit tests, fixtures, and other test apparatus. These are covered in "Testing Rails Applications":testing.html|
 |tmp/|Temporary files|
-|vendor/|A place for third-party code. In a typical Rails application, this includes Ruby Gems, the Rails source code (if you install it into your project) and plugins containing additional prepackaged functionality.|
+|vendor/|A place for all third-party code. In a typical Rails application, this includes Ruby Gems, the Rails source code (if you install it into your project) and plugins containing additional prepackaged functionality.|
+
+h4. Installing the Required Gems
+
+Rails uses the _Bundler_ gem to populate the +vendor+ directory with all the gems your application depends on.  As we don't need any special gems beyond the default, we just need to do the following:
+
+<shell>
+$ gem install bundle
+$ gem bundle
+</shell>
+
+This will copy down the latest versions of all the gems you need to start a rails application.
 
 h4. Configuring a Database
 
@@ -255,19 +267,11 @@ NOTE. Rake is a general-purpose command-runner that Rails uses for many things.
 
 h3. Hello, Rails!
 
-One of the traditional places to start with a new language is by getting some text up on screen quickly. To do that in Rails, you need to create at minimum a controller and a view. Fortunately, you can do that in a single command. Enter this command in your terminal:
-
-<shell>
-$ script/generate controller home index
-</shell>
-
-TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
+One of the traditional places to start with a new language is by getting some text up on screen quickly, to do this, you need to get your Rails application server running.
 
-Rails will create several files for you, including +app/views/home/index.html.erb+. This is the template that will be used to display the results of the +index+ action (method) in the +home+ controller. Open this file in your text editor and edit it to contain a single line of code:
+h4. Before we begin
 
-<code class="html">
-<h1>Hello, Rails!</h1>
-</code>
+As an added help, you can find all the code of this application in a ready to run Git repository at "http://github.com/mikel/getting-started-code":http://github.com/mikel/getting-started-code.
 
 h4. Starting up the Web Server
 
@@ -283,34 +287,51 @@ This will fire up an instance of the Mongrel web server by default (Rails can al
 
 TIP: To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to stop the server; changes you make in files will be automatically picked up by the server.
 
-The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page. To view the page you just created, navigate to +http://localhost:3000/home/index+.
+The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page.  You can also click on the +About your application’s environment+ link to see a summary of your Application's environment.
+
+h4. Say "Hello", Rails
+
+To get Rails saying "Hello", you need to create at minimum a controller and a view. Fortunately, you can do that in a single command. Enter this command in your terminal:
+
+<shell>
+$ script/generate controller home index
+</shell>
+
+TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
+
+Rails will create several files for you, including +app/views/home/index.html.erb+. This is the template that will be used to display the results of the +index+ action (method) in the +home+ controller. Open this file in your text editor and edit it to contain a single line of code:
+
+<code class="html">
+<h1>Hello, Rails!</h1>
+</code>
 
 h4. Setting the Application Home Page
 
-You'd probably like to replace the "Welcome Aboard" page with your own application's home page. The first step to doing this is to delete the default page from your application:
+Now that we have made the controller and view, we need to tell Rails when we want "Hello Rails" to show up.  In our case, we want it to show up when we navigate to the root URL of our site, +http://127.0.0.1:3000/+, instead of the "Welcome Aboard" smoke test.
+
+The first step to doing this is to delete the default page from your application:
 
 <shell>
 $ rm public/index.html
 </shell>
 
-Now, you have to tell Rails where your actual home page is located. Open the file +config/routes.rb+ in your editor. This is your application's, _routing file_, which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. At the bottom of the file you'll see the _default routes_:
+We need to do this as Rails will deliver any static file in the +public+ directory in preference to any dynamic contact we generate from the controllers.
 
-<ruby>
-map.connect ':controller/:action/:id'
-map.connect ':controller/:action/:id.:format'
-</ruby>
+Now, you have to tell Rails where your actual home page is located. Open the file +config/routes.rb+ in your editor. This is your application's, _routing file_, which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. There are only comments in this file, so we need to add at the top the following:
 
-The default routes handle simple requests such as +/home/index+: Rails translates that into a call to the +index+ action in the +home+ controller. As another example, +/posts/edit/1+ would run the +edit+ action in the +posts+ controller with an +id+ of 1.
+<ruby>
+Blog::Application.routes.draw do |map|
 
-To hook up your home page, you need to add another line to the routing file, above the default routes:
+  root :to => "home#index"
 
-<ruby>
-map.root :controller => "home"
+  # The priority is based upon order of creation:
+  # first created -> highest priority.
+  #...
 </ruby>
 
-This line illustrates one tiny bit of the "convention over configuration" approach: if you don't specify an action, Rails assumes the +index+ action.
+The +root :to => "home#index"+ tells Rails to map the root action to the home controller's index action.
 
-Now if you navigate to +http://localhost:3000+ in your browser, you'll see the +home/index+ view.
+Now if you navigate to +http://localhost:3000+ in your browser, you'll see +Hello, Rails!+.
 
 NOTE. For more information about routing, refer to "Rails Routing from the Outside In":routing.html.
 
@@ -330,28 +351,29 @@ NOTE. While scaffolding will get you up and running quickly, the "one size fits
 
 The scaffold generator will build 14 files in your application, along with some folders, and edit one more. Here's a quick overview of what it creates:
 
-|_.File                                        |_.Purpose|
-|app/models/post.rb                            |The Post model|
-|db/migrate/20090113124235_create_posts.rb     |Migration to create the posts table in your database (your name will include a different timestamp)|
-|app/views/posts/index.html.erb                |A view to display an index of all posts |
-|app/views/posts/show.html.erb                 |A view to display a single post|
-|app/views/posts/new.html.erb                  |A view to create a new post|
-|app/views/posts/edit.html.erb                 |A view to edit an existing post|
-|app/views/layouts/posts.html.erb              |A view to control the overall look and feel of the other posts views|
-|public/stylesheets/scaffold.css               |Cascading style sheet to make the scaffolded views look better|
-|app/controllers/posts_controller.rb           |The Posts controller|
-|test/functional/posts_controller_test.rb      |Functional testing harness for the posts controller|
-|app/helpers/posts_helper.rb                   |Helper functions to be used from the posts views|
-|config/routes.rb                              |Edited to include routing information for posts|
-|test/fixtures/posts.yml                       |Dummy posts for use in testing|
-|test/unit/post_test.rb                        |Unit testing harness for the posts model|
-|test/unit/helpers/posts_helper_test.rb        |Unit testing harness for the posts helper|
+|_.File                                       |_.Purpose|
+|app/models/post.rb                           |The Post model|
+|db/migrate/20100123083454_create_posts.rb    |Migration to create the posts table in your database (your name will include a different timestamp)|
+|app/views/posts/index.html.erb|              |A view to display an index of all posts |
+|app/views/posts/edit.html.erb                |A view to display a single post|
+|app/views/posts/show.html.erb                |A view to create a new post|
+|app/views/posts/new.html.erb                 |A view to edit an existing post|
+|app/views/posts/_form.html.erb               |A view to control the overall look and feel of the other posts views|
+|app/views/layouts/posts.html.erb             |A view to control the overall look and feel of the other posts views|
+|public/stylesheets/scaffold.css              |Cascading style sheet to make the scaffolded views look better|
+|app/controllers/posts_controller.rb          |The Posts controller|
+|test/functional/posts_controller_test.rb     |Functional testing harness for the posts controller|
+|app/helpers/posts_helper.rb                  |Helper functions to be used from the posts views|
+|config/routes.rb                             |Edited to include routing information for posts|
+|test/fixtures/posts.yml                      |Dummy posts for use in testing|
+|test/unit/post_test.rb                       |Unit testing harness for the posts model|
+|test/unit/helpers/posts_helper_test.rb       |Unit testing harness for the posts helper|
 
 h4. Running a Migration
 
 One of the products of the +script/generate scaffold+ command is a _database migration_. Migrations are Ruby classes that are designed to make it simple to create and modify database tables. Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database. Migration filenames include a timestamp to ensure that they're processed in the order that they were created.
 
-If you look in the +db/migrate/20090113124235_create_posts.rb+ file (remember, yours will have a slightly different name), here's what you'll find:
+If you look in the +db/migrate/20100123083454_create_posts.rb+ file (remember, yours will have a slightly different name), here's what you'll find:
 
 <ruby>
 class CreatePosts < ActiveRecord::Migration
@@ -381,6 +403,15 @@ $ rake db:migrate
 
 Remember, you can't run migrations before running +rake db:create+ to create your database, as we covered earlier.
 
+Rails will execute this migration command and tell you is created the Posts table.
+
+<shell>
+==  CreatePosts: migrating =================================================
+-- create_table(:posts)
+   -> 0.0019s
+==  CreatePosts: migrated (0.0020s) ========================================
+</shell>
+
 NOTE. Because you're working in the development environment by default, this command will apply to the database defined in the +development+ section of your +config/database.yml+ file.
 
 h4. Adding a Link
@@ -423,8 +454,9 @@ Rails includes methods to help you validate the data that you send to models. Op
 
 <ruby>
 class Post < ActiveRecord::Base
-  validates_presence_of :name, :title
-  validates_length_of :title, :minimum => 5
+  validates :name,  :presence => true
+  validates :title, :presence => true,
+                    :length => { :minimum => 5 }
 end
 </ruby>
 
@@ -447,10 +479,7 @@ created_at: nil, updated_at: nil>
 >> p.save
 => false
 >> p.errors
-=> #<ActiveRecord::Errors:0x23bcf0c @base=#<Post id: nil, name: nil,
-title: nil, content: "A new post", created_at: nil, updated_at: nil>,
-@errors={"name"=>["can't be blank"], "title"=>["can't be blank",
-"is too short (minimum is 5 characters)"]}>
+=> #<OrderedHash {:title=>["can't be blank", "is too short (minimum is 5 characters)"], :name=>["can't be blank"]}>
 </shell>
 
 This code shows creating a new +Post+ instance, attempting to save it and getting +false+ for a return value (indicating that the save failed), and inspecting the +errors+ of the post.
@@ -472,7 +501,7 @@ def index
 end
 </ruby>
 
-This code sets the +@posts+ instance variable to an array of all posts in the database. +Post.find(:all)+ or +Post.all+ calls the +Post+ model to return all of the posts that are currently in the database, with no limiting conditions.
+This code sets the +@posts+ instance variable to an array of all posts in the database. +Post.all+ calls the +Post+ model to return all of the posts that are currently in the database, with no limiting conditions.
 
 TIP: For more information on finding records with Active Record, see "Active Record Query Interface":active_record_querying.html.
 
@@ -486,17 +515,19 @@ The +respond_to+ block handles both HTML and XML calls to this action. If you br
     <th>Name</th>
     <th>Title</th>
     <th>Content</th>
+    <th></th>
+    <th></th>
+    <th></th>
   </tr>
 
 <% @posts.each do |post| %>
   <tr>
-    <td><%=h post.name %></td>
-    <td><%=h post.title %></td>
-    <td><%=h post.content %></td>
+    <td><%= post.name %></td>
+    <td><%= post.title %></td>
+    <td><%= post.content %></td>
     <td><%= link_to 'Show', post %></td>
     <td><%= link_to 'Edit', edit_post_path(post) %></td>
-    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?',
-            :method => :delete %></td>
+    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %></td>
   </tr>
 <% end %>
 </table>
@@ -508,10 +539,11 @@ The +respond_to+ block handles both HTML and XML calls to this action. If you br
 
 This view iterates over the contents of the +@posts+ array to display content and links. A few things to note in the view:
 
-* +h+ is a Rails helper method to sanitize displayed data, preventing cross-site scripting attacks
 * +link_to+ builds a hyperlink to a particular destination
 * +edit_post_path+ is a helper that Rails provides as part of RESTful routing. You'll see a variety of these helpers for the different actions that the controller includes.
 
+NOTE. In previous versions of Rails, you had to use +<%=h post.name %>+ so that any HTML would be escaped before being inserted into the page.  In Rails 3.0, this is now the default.  To get unescaped HTML, you now use +<%= raw post.name %>+.
+
 TIP: For more details on the rendering process, see "Layouts and Rendering in Rails":layouts_and_rendering.html.
 
 h4. Customizing the Layout
@@ -519,21 +551,17 @@ h4. Customizing the Layout
 The view is only part of the story of how HTML is displayed in your web browser. Rails also has the concept of +layouts+, which are containers for views. When Rails renders a view to the browser, it does so by putting the view's HTML into a layout's HTML. The +script/generate scaffold+ command automatically created a default layout, +app/views/layouts/posts.html.erb+, for the posts. Open this layout in your editor and modify the +body+ tag:
 
 <erb>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
-       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<!DOCTYPE html>
+<html>
 <head>
-  <meta http-equiv="content-type"
-        content="text/html;charset=UTF-8" />
   <title>Posts: <%= controller.action_name %></title>
   <%= stylesheet_link_tag 'scaffold' %>
 </head>
 <body style="background: #EEEEEE;">
 
-<p style="color: green"><%= flash[:notice] %></p>
+<p class="notice"><%= notice %></p>
 
-<%= yield  %>
+<%= yield %>
 
 </body>
 </html>
@@ -561,34 +589,48 @@ The +new.html.erb+ view displays this empty Post to the user:
 <erb>
 <h1>New post</h1>
 
+<%= render 'form' %>
+
+<%= link_to 'Back', posts_path %>
+</erb>
+
+The +<%= render 'form' %>+ line is our first introduction to _partials_ in Rails.  A partial is a snippet of HTML and Ruby code that can be reused in multiple locations.  In this case, the form used to make a new post, is very similar to a form used to edit a post, both have text fields for the name and title and a text area for the content with a button to make a new post or update the existing post.
+
+If you take a look at +views/posts/_form.html.erb+ file, you will see the following:
+
+<erb>
 <% form_for(@post) do |f| %>
   <%= f.error_messages %>
 
-  <p>
+  <div class="field">
     <%= f.label :name %><br />
     <%= f.text_field :name %>
-  </p>
-  <p>
+  </div>
+  <div class="field">
     <%= f.label :title %><br />
     <%= f.text_field :title %>
-  </p>
-  <p>
+  </div>
+  <div class="field">
     <%= f.label :content %><br />
     <%= f.text_area :content %>
-  </p>
-  <p>
-    <%= f.submit "Create" %>
-  </p>
+  </div>
+  <div class="actions">
+    <%= f.submit %>
+  </div>
 <% end %>
-
-<%= link_to 'Back', posts_path %>
 </erb>
 
+This partial receives all the instance variables defined in the calling view file, so in this case, the controller assigned the new Post object to +@post+ and so, this is available in both the view and partial as +@post+.
+
+For more information on partials, refer to the "Layouts and Rendering in Rails":layouts_and_rendering.html#using-partials guide.
+
 The +form_for+ block is used to create an HTML form. Within this block, you have access to methods to build various controls on the form. For example, +f.text_field :name+ tells Rails to create a text input on the form, and to hook it up to the +name+ attribute of the instance being displayed. You can only use these methods with attributes of the model that the form is based on (in this case +name+, +title+, and +content+). Rails uses +form_for+ in preference to having you write raw HTML because the code is more succinct, and because it explicitly ties the form to a particular model instance.
 
+The +form_for+ block is also smart enough to work out if you are doing a _New Post_ or an _Edit Post_ action, and will set the form +action+ tags and submit button names appropriately in the HTML output.
+
 TIP: If you need to create an HTML form that displays arbitrary fields, not tied to a model, you should use the +form_tag+ method, which provides shortcuts for building forms that are not necessarily tied to a model instance.
 
-When the user clicks the +Create+ button on this form, the browser will send information back to the +create+ method of the controller (Rails knows to call the +create+ method because the form is sent with an HTTP POST request; that's one of the conventions that I mentioned earlier):
+When the user clicks the +Create Post+ button on this form, the browser will send information back to the +create+ method of the controller (Rails knows to call the +create+ method because the form is sent with an HTTP POST request; that's one of the conventions that I mentioned earlier):
 
 <ruby>
 def create
@@ -596,22 +638,24 @@ def create
 
   respond_to do |format|
     if @post.save
-      flash[:notice] = 'Post was successfully created.'
-      format.html { redirect_to(@post) }
-      format.xml  { render :xml => @post, :status => :created,
-	                :location => @post }
+      format.html { redirect_to(@post,
+                    :notice => 'Post was successfully created.') }
+      format.xml  { render :xml => @post,
+                    :status => :created, :location => @post }
     else
       format.html { render :action => "new" }
       format.xml  { render :xml => @post.errors,
-	                :status => :unprocessable_entity }
+                    :status => :unprocessable_entity }
     end
   end
 end
 </ruby>
 
-The +create+ action instantiates a new Post object from the data supplied by the user on the form, which Rails makes available in the +params+ hash. After saving the new post, it uses +flash[:notice]+ to create an informational message for the user, and redirects to the show action for the post. If there's any problem, the +create+ action just shows the +new+ view a second time, with any error messages.
+The +create+ action instantiates a new Post object from the data supplied by the user on the form, which Rails makes available in the +params+ hash. After successfully saving the new post, returns the appropriate format that the user has requested (HTML in our case). It then redirects the user to the resulting post +show+ action and sets a notice to the user that the Post was successfully created.
 
-Rails provides the +flash+ hash (usually just called the Flash) so that messages can be carried over to another action, providing the user with useful information on the status of their request. In the case of +create+, the user never actually sees any page rendered during the Post creation process, because it immediately redirects to the new Post as soon Rails saves the record. The Flash carries over a message to the next action, so that when the user is redirected back to the +show+ action, they are presented with a message saying "Post was successfully created."
+If the post was not successfully saved, due to a validation error, then the controller returns the user back to the +new+ action with any error messages so that the user has the chance to fix the error and try again.
+
+The "Post was successfully created" message is stored inside of the Rails +flash+ hash, (usually just called the Flash) so that messages can be carried over to another action, providing the user with useful information on the status of their request. In the case of +create+, the user never actually sees any page rendered during the Post creation process, because it immediately redirects to the new Post as soon Rails saves the record. The Flash carries over a message to the next action, so that when the user is redirected back to the +show+ action, they are presented with a message saying "Post was successfully created."
 
 h4. Showing an Individual Post
 
@@ -633,17 +677,17 @@ The +show+ action uses +Post.find+ to search for a single record in the database
 <erb>
 <p>
   <b>Name:</b>
-  <%=h @post.name %>
+  <%= @post.name %>
 </p>
 
 <p>
   <b>Title:</b>
-  <%=h @post.title %>
+  <%= @post.title %>
 </p>
 
 <p>
   <b>Content:</b>
-  <%=h @post.content %>
+  <%= @post.content %>
 </p>
 
 
@@ -666,30 +710,15 @@ After finding the requested post, Rails uses the +edit.html.erb+ view to display
 <erb>
 <h1>Editing post</h1>
 
-<% form_for(@post) do |f| %>
-  <%= f.error_messages %>
-
-  <p>
-    <%= f.label :name %><br />
-    <%= f.text_field :name %>
-  </p>
-  <p>
-    <%= f.label :title %><br />
-    <%= f.text_field :title %>
-  </p>
-  <p>
-    <%= f.label :content %><br />
-    <%= f.text_area :content %>
-  </p>
-  <p>
-    <%= f.submit "Update" %>
-  </p>
-<% end %>
+<%= render 'form' %>
 
 <%= link_to 'Show', @post %> |
 <%= link_to 'Back', posts_path %>
+<% end %>
 </erb>
 
+Again, as with the +new+ action, the +edit+ action is using the +form+ partial, this time however, the form will do a PUT action to the PostsController and the submit button will display "Update Post"
+
 Submitting the form created by this view will invoke the +update+ action within the controller:
 
 <ruby>
@@ -698,13 +727,13 @@ def update
 
   respond_to do |format|
     if @post.update_attributes(params[:post])
-      flash[:notice] = 'Post was successfully updated.'
-      format.html { redirect_to(@post) }
+      format.html { redirect_to(@post, 
+                    :notice => 'Post was successfully updated.') }
       format.xml  { head :ok }
     else
       format.html { render :action => "edit" }
       format.xml  { render :xml => @post.errors,
-	                :status => :unprocessable_entity }
+                    :status => :unprocessable_entity }
     end
   end
 end
@@ -712,8 +741,6 @@ end
 
 In the +update+ action, Rails first uses the +:id+ parameter passed back from the edit view to locate the database record that's being edited. The +update_attributes+ call then takes the rest of the parameters from the request and applies them to this record. If all goes well, the user is redirected to the post's +show+ view. If there are any problems, it's back to +edit+ to correct them.
 
-NOTE. Sharp-eyed readers will have noticed that the +form_for+ declaration is identical for the +new+ and +edit+ views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a _partial template_, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that's easy to modify if you want different forms for +create+ and +edit+.
-
 h4. Destroying a Post
 
 Finally, clicking one of the +destroy+ links sends the associated id to the +destroy+ action:
@@ -734,60 +761,7 @@ The +destroy+ method of an Active Record model instance removes the correspondin
 
 h3. DRYing up the Code
 
-At this point, it's worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views and _filters_ to help with duplication in controllers.
-
-h4. Using Partials to Eliminate View Duplication
-
-As you saw earlier, the scaffold-generated views for the +new+ and +edit+ actions are largely identical. You can pull the shared code out into a partial template. This requires editing the new and edit views, and adding a new template. The new +_form.html.erb+ template should be saved in the same +app/views/posts+ folder as the files from which it is being extracted. Note that the name of this file begins with an underscore; that's the Rails naming convention for partial templates.
-
-<tt>new.html.erb</tt>:
-
-<erb>
-<h1>New post</h1>
-
-<%= render :partial => "form" %>
-
-<%= link_to 'Back', posts_path %>
-</erb>
-
-<tt>edit.html.erb</tt>:
-
-<erb>
-<h1>Editing post</h1>
-
-<%= render :partial => "form" %>
-
-<%= link_to 'Show', @post %> |
-<%= link_to 'Back', posts_path %>
-</erb>
-
-<tt>_form.html.erb</tt>:
-
-<erb>
-<% form_for(@post) do |f| %>
-  <%= f.error_messages %>
-
-  <p>
-    <%= f.label :name %><br />
-    <%= f.text_field :name %>
-  </p>
-  <p>
-    <%= f.label :title, "title" %><br />
-    <%= f.text_field :title %>
-  </p>
-  <p>
-    <%= f.label :content %><br />
-    <%= f.text_area :content %>
-  </p>
-  <p>
-    <%= f.submit "Save" %>
-  </p>
-<% end %>
-</erb>
-
-Now, when Rails renders the +new+ or +edit+ view, it will insert the +_form+ partial at the indicated point. Note the naming convention for partials: if you refer to a partial named +form+ inside of a view, the corresponding file is +_form.html.erb+, with a leading underscore.
-
-For more information on partials, refer to the "Layouts and Rendering in Rails":layouts_and_rendering.html#using-partials guide.
+At this point, it's worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views (as you saw above with the +new+ and +edit+ views both sharing the +form+ partial) and _filters_ to help with duplication in controllers.
 
 h4. Using Filters to Eliminate Controller Duplication
 
@@ -859,14 +833,13 @@ h4. Generating a Model
 Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:
 
 <shell>
-$ script/generate model Comment commenter:string body:text
-    post:references
+$ script/generate model Comment commenter:string body:text  post:references
 </shell>
 
 This command will generate four files:
 
 * +app/models/comment.rb+ - The model
-* +db/migrate/20091013214407_create_comments.rb+ - The migration
+* +db/migrate/20100124023310_create_comments.rb+ - The migration
 * +test/unit/comment_test.rb+ and +test/fixtures/comments.yml+ - The test harness.
 
 First, take a look at +comment.rb+:
@@ -905,7 +878,14 @@ The +t.references+ line sets up a foreign key column for the association between
 $ rake db:migrate
 </shell>
 
-Rails is smart enough to only execute the migrations that have not already been run against the current database.
+Rails is smart enough to only execute the migrations that have not already been run against the current database, so in this case you will just see:
+
+<shell>
+==  CreateComments: migrating =================================================
+-- create_table(:comments)
+   -> 0.0019s
+==  CreateComments: migrated (0.0020s) ========================================
+</shell>
 
 h4. Associating Models
 
@@ -926,8 +906,9 @@ You'll need to edit the +post.rb+ file to add the other side of the association:
 
 <ruby>
 class Post < ActiveRecord::Base
-  validates_presence_of :name, :title
-  validates_length_of :title, :minimum => 5
+  validates :name,  :presence => true
+  validates :title, :presence => true,
+                    :length => { :minimum => 5 }
   has_many :comments
 end
 </ruby>
@@ -936,12 +917,14 @@ These two declarations enable a good bit of automatic behavior. For example, if
 
 TIP: For more information on Active Record associations, see the "Active Record Associations":association_basics.html guide.
 
-h4. Adding a Route
+h4. Adding a Route for Comments
 
-_Routes_ are entries in the +config/routes.rb+ file that tell Rails how to match incoming HTTP requests to controller actions. Open up that file and find the existing line referring to +posts+ (it will be right at the top of the file). Then edit it as follows:
+As with the +home+ controller, we will need to add a route so that Rails knows where we would like to navigate to see +comments+.  Open up the +config/routes.rb+ file again, you will see an entry that was added automatically for +posts+ near the top by the scaffold generator, +resources :posts+, edit it as follows:
 
 <ruby>
-map.resources :posts, :has_many => :comments
+resources :posts do
+  resources :comments
+end
 </ruby>
 
 This creates +comments+ as a _nested resource_ within +posts+. This is another part of capturing the hierarchical relationship that exists between posts and comments.
@@ -1063,20 +1046,19 @@ The +views/comments/index.html.erb+ view:
   <tr>
     <th>Commenter</th>
     <th>Body</th>
+    <th></th>
+    <th></th>
+    <th></th>
   </tr>
 
-<% for comment in @comments %>
+<% @comments.each do |comment| %>
   <tr>
-    <td><%=h comment.commenter %></td>
-    <td><%=h comment.body %></td>
+    <td><%= comment.commenter %></td>
+    <td><%= comment.body %></td>
     <td><%= link_to 'Show', post_comment_path(@post, comment) %></td>
-    <td>
-        <%= link_to 'Edit', edit_post_comment_path(@post, comment) %>
-    </td>
-    <td>
-        <%= link_to 'Destroy', post_comment_path(@post, comment),
-            :confirm => 'Are you sure?', :method => :delete %>
-    </td>
+    <td><%= link_to 'Edit', edit_post_comment_path(@post, comment) %></td>
+    <td><%= link_to 'Destroy', post_comment_path(@post, comment), 
+                    :confirm => 'Are you sure?', :method => :delete %></td>
   </tr>
 <% end %>
 </table>
@@ -1087,28 +1069,45 @@ The +views/comments/index.html.erb+ view:
 <%= link_to 'Back to Post', @post %>
 </erb>
 
-The +views/comments/new.html.erb+ view:
+The +views/comments/new.html.erb+ view (again using a partial to render a form that is shared with the +edit+ view):
 
 <erb>
 <h1>New comment</h1>
 
+<%= render 'form' %>
+
+<%= link_to 'Back', post_comments_path(@post) %>
+</erb>
+
+The +views/comments/edit.html.erb+ view:
+
+<erb>
+<h1>Editing comment</h1>
+
+<%= render 'form' %>
+
+<%= link_to 'Show', post_comment_path(@post, @comment) %> |
+<%= link_to 'Back', post_comments_path(@post) %>
+</erb>
+
+The +views/comments/_form.html.erb+ partial:
+
+<erb>
 <% form_for([@post, @comment]) do |f| %>
   <%= f.error_messages %>
 
-  <p>
+  <div class="field">
     <%= f.label :commenter %><br />
     <%= f.text_field :commenter %>
-  </p>
-  <p>
+  </div>
+  <div class="field">
     <%= f.label :body %><br />
     <%= f.text_area :body %>
-  </p>
-  <p>
-    <%= f.submit "Create" %>
-  </p>
+  </div>
+  <div class="actions">
+    <%= f.submit %>
+  </div>
 <% end %>
-
-<%= link_to 'Back', post_comments_path(@post) %>
 </erb>
 
 The +views/comments/show.html.erb+ view:
@@ -1118,43 +1117,18 @@ The +views/comments/show.html.erb+ view:
 
 <p>
   <b>Commenter:</b>
-  <%=h @comment.commenter %>
+  <%= @comment.commenter %>
 </p>
 
 <p>
   <b>Comment:</b>
-  <%=h @comment.body %>
+  <%= @comment.body %>
 </p>
 
 <%= link_to 'Edit', edit_post_comment_path(@post, @comment) %> |
 <%= link_to 'Back', post_comments_path(@post) %>
 </erb>
 
-The +views/comments/edit.html.erb+ view:
-
-<erb>
-<h1>Editing comment</h1>
-
-<% form_for([@post, @comment]) do |f| %>
-  <%= f.error_messages %>
-
-  <p>
-    <%= f.label :commenter %><br />
-    <%= f.text_field :commenter %>
-  </p>
-  <p>
-    <%= f.label :body %><br />
-    <%= f.text_area :body %>
-  </p>
-  <p>
-    <%= f.submit "Update" %>
-  </p>
-<% end %>
-
-<%= link_to 'Show', post_comment_path(@post, @comment) %> |
-<%= link_to 'Back', post_comments_path(@post) %>
-</erb>
-
 Again, the added complexity here (compared to the views you saw for managing posts) comes from the necessity of juggling a post and its comments at the same time.
 
 h4. Hooking Comments to Posts
@@ -1164,29 +1138,29 @@ As a next step, I'll modify the +views/posts/show.html.erb+ view to show the com
 <erb>
 <p>
   <b>Name:</b>
-  <%=h @post.name %>
+  <%= @post.name %>
 </p>
 
 <p>
   <b>Title:</b>
-  <%=h @post.title %>
+  <%= @post.title %>
 </p>
 
 <p>
   <b>Content:</b>
-  <%=h @post.content %>
+  <%= @post.content %>
 </p>
 
 <h2>Comments</h2>
-<% @post.comments.each do |c| %>
+<% @post.comments.each do |comment| %>
   <p>
     <b>Commenter:</b>
-    <%=h c.commenter %>
+    <%= comment.commenter %>
   </p>
 
   <p>
     <b>Comment:</b>
-    <%=h c.body %>
+    <%= comment.body %>
   </p>
 <% end %>
 
@@ -1203,21 +1177,22 @@ If you decide at some point to delete a post, you likely want to delete the comm
 
 <ruby>
 class Post < ActiveRecord::Base
-  validates_presence_of :name, :title
-  validates_length_of :title, :minimum => 5
+  validates :name,  :presence => true
+  validates :title, :presence => true,
+                    :length => { :minimum => 5 }
   has_many :comments, :dependent => :destroy
 end
 </ruby> 
 
 h3. Building a Multi-Model Form
 
-Comments and posts are edited on two separate forms - which makes sense, given the flow of this mini-application. But what if you want to edit more than one thing on a single form? Rails 2.3 offers new support for nested forms. Let's add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
+Comments and posts are edited on two separate forms - which makes sense, given the flow of this mini-application. But what if you want to edit more than one thing on a single form? Rails offers support for nested forms. Let's add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
 
 <shell>
 $ script/generate model tag name:string post:references
 </shell>
 
-Run the migration to create the database table:
+Again, run the migration to create the database table:
 
 <shell>
 $ rake db:migrate
@@ -1227,8 +1202,9 @@ Next, edit the +post.rb+ file to create the other side of the association, and t
 
 <ruby>
 class Post < ActiveRecord::Base
-  validates_presence_of :name, :title
-  validates_length_of :title, :minimum => 5
+  validates :name,  :presence => true
+  validates :title, :presence => true,
+                    :length => { :minimum => 5 }
   has_many :comments
   has_many :tags
 
@@ -1246,47 +1222,49 @@ You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
 <% form_for(@post) do |post_form| %>
   <%= post_form.error_messages %>
 
-  <p>
+  <div class="field">
     <%= post_form.label :name %><br />
     <%= post_form.text_field :name %>
-  </p>
-  <p>
-    <%= post_form.label :title, "Title" %><br />
+  </div>
+  <div class="field">
+    <%= post_form.label :title %><br />
     <%= post_form.text_field :title %>
-  </p>
-  <p>
+  </div>
+  <div class="field">
     <%= post_form.label :content %><br />
     <%= post_form.text_area :content %>
-  </p>
+  </div>
   <h2>Tags</h2>
   <% post_form.fields_for :tags do |tag_form| %>
-    <p>
+    <div class="field">
       <%= tag_form.label :name, 'Tag:' %>
       <%= tag_form.text_field :name %>
-    </p>
+    </div>
     <% unless tag_form.object.nil? || tag_form.object.new_record? %>
-      <p>
+      <div class="field">
         <%= tag_form.label :_delete, 'Remove:' %>
         <%= tag_form.check_box :_delete %>
-      </p>
+      </div>
     <% end %>
   <% end %>
 
-  <p>
-    <%= post_form.submit "Save" %>
-  </p>
+  <div class="actions">
+    <%= post_form.submit %>
+  </div>
 <% end %>
 </erb>
 
+You will note that we also have changed the +form_for(@post) do |f|+ to +form_for(@post) do |post_form|+ and changed all the +f+ method calls as well to show more clearly what is going on.
+
 With these changes in place, you'll find that you can edit a post and its tags directly on the same view.
 
-NOTE. You may want to use JavaScript to dynamically add additional tags on a single form. For an example of this and other advanced techniques, see the "complex form examples application":http://github.com/alloy/complex-form-examples/tree/master.
+NOTE. You may want to use JavaScript to dynamically add additional tags on a single form. For an example of this and other advanced techniques, see the "complex form examples application":http://github.com/mikel/complex-form-examples/.
 
 h3. What's Next?
 
 Now that you've seen your first Rails application, you should feel free to update it and experiment on your own. But you don't have to do everything without help. As you need assistance getting up and running with Rails, feel free to consult these support resources:
 
-* The "Ruby On Rails guides":http://guides.rubyonrails.org
+* The "Ruby On Rails guides":http://guides.rails.info
 * The "Ruby on Rails mailing list":http://groups.google.com/group/rubyonrails-talk
 * The "#rubyonrails":irc://irc.freenode.net/#rubyonrails channel on irc.freenode.net
 * The "Rails Wiki":http://wiki.rubyonrails.org/
@@ -1299,7 +1277,9 @@ Rails also comes with built-in help that you can generate using the rake command
 h3. Changelog
 
 "Lighthouse ticket":http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2
+"Lighthouse ticket for accepts_nested_attributes_for bug":https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3779
 
+* January 24, 2010: Re-write for Rails 3.0 by "Mikel Lindsaar":credits:html#raasdnil
 * July 18, 2009: Minor cleanup in anticipation of Rails 2.3.3 by "Mike Gunderloy":credits.html#mgunderloy
 * February 1, 2009: Updated for Rails 2.3 by "Mike Gunderloy":credits.html#mgunderloy
 * November 3, 2008: Formatting patch from Dave Rothlisberger
-- 
cgit v1.2.3


From 5742a72b8a116e4f4e387ab345d62ac3215c3bba Mon Sep 17 00:00:00 2001
From: Mikel Lindsaar <raasdnil@gmail.com>
Date: Sun, 24 Jan 2010 19:31:39 +1100
Subject: Fixed :_delete is now :_destroy in Rails 3.0

---
 railties/guides/source/getting_started.textile | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 4d406c09da..2886df3b63 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -1218,7 +1218,7 @@ The +:allow_destroy+ option on the nested attribute declaration tells Rails to d
 You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
 
 <erb>
-<% @post.tags.build if @post.tags.empty? %>
+<% @post.tags.build %>
 <% form_for(@post) do |post_form| %>
   <%= post_form.error_messages %>
 
@@ -1242,8 +1242,8 @@ You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
     </div>
     <% unless tag_form.object.nil? || tag_form.object.new_record? %>
       <div class="field">
-        <%= tag_form.label :_delete, 'Remove:' %>
-        <%= tag_form.check_box :_delete %>
+        <%= tag_form.label :_destroy, 'Remove:' %>
+        <%= tag_form.check_box :_destroy %>
       </div>
     <% end %>
   <% end %>
@@ -1277,7 +1277,6 @@ Rails also comes with built-in help that you can generate using the rake command
 h3. Changelog
 
 "Lighthouse ticket":http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2
-"Lighthouse ticket for accepts_nested_attributes_for bug":https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3779
 
 * January 24, 2010: Re-write for Rails 3.0 by "Mikel Lindsaar":credits:html#raasdnil
 * July 18, 2009: Minor cleanup in anticipation of Rails 2.3.3 by "Mike Gunderloy":credits.html#mgunderloy
-- 
cgit v1.2.3


From c3743c7ff777ac796319f14e306aaf4b7af8585c Mon Sep 17 00:00:00 2001
From: Mikel Lindsaar <raasdnil@gmail.com>
Date: Mon, 25 Jan 2010 19:10:15 +1100
Subject: Updated formatting on shell code to fit

---
 railties/guides/source/getting_started.textile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 2886df3b63..3ad73ad038 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -479,7 +479,9 @@ created_at: nil, updated_at: nil>
 >> p.save
 => false
 >> p.errors
-=> #<OrderedHash {:title=>["can't be blank", "is too short (minimum is 5 characters)"], :name=>["can't be blank"]}>
+=> #<OrderedHash {:title=>["can't be blank", 
+                  "is too short (minimum is 5 characters)"],
+                  :name=>["can't be blank"]}>
 </shell>
 
 This code shows creating a new +Post+ instance, attempting to save it and getting +false+ for a return value (indicating that the save failed), and inspecting the +errors+ of the post.
-- 
cgit v1.2.3


From b204d9477cc9d709fd7b45a89ec7e13e0bab6b1a Mon Sep 17 00:00:00 2001
From: James Miller <james@jkmillertech.com>
Date: Wed, 27 Jan 2010 09:23:42 -0800
Subject: Fix view description mismatch

---
 railties/guides/source/getting_started.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 3ad73ad038..23967e4a7f 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -355,9 +355,9 @@ The scaffold generator will build 14 files in your application, along with some
 |app/models/post.rb                           |The Post model|
 |db/migrate/20100123083454_create_posts.rb    |Migration to create the posts table in your database (your name will include a different timestamp)|
 |app/views/posts/index.html.erb|              |A view to display an index of all posts |
-|app/views/posts/edit.html.erb                |A view to display a single post|
-|app/views/posts/show.html.erb                |A view to create a new post|
-|app/views/posts/new.html.erb                 |A view to edit an existing post|
+|app/views/posts/edit.html.erb                |A view to edit an existing post|
+|app/views/posts/show.html.erb                |A view to display a single post|
+|app/views/posts/new.html.erb                 |A view to create a new post|
 |app/views/posts/_form.html.erb               |A view to control the overall look and feel of the other posts views|
 |app/views/layouts/posts.html.erb             |A view to control the overall look and feel of the other posts views|
 |public/stylesheets/scaffold.css              |Cascading style sheet to make the scaffolded views look better|
-- 
cgit v1.2.3


From d546a72d00d084d9016593f67c52078d21d273d4 Mon Sep 17 00:00:00 2001
From: James Miller <james@jkmillertech.com>
Date: Wed, 27 Jan 2010 09:51:46 -0800
Subject: Add my info to the credits

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 23967e4a7f..c173748944 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -1288,4 +1288,4 @@ h3. Changelog
 * October 16, 2008: Revised based on feedback from Pratik Naik by "Mike Gunderloy":credits.html#mgunderloy (not yet approved for publication)
 * October 13, 2008: First complete draft by "Mike Gunderloy":credits.html#mgunderloy (not yet approved for publication)
 * October 12, 2008: More detail, rearrangement, editing by "Mike Gunderloy":credits.html#mgunderloy (not yet approved for publication)
-* September 8, 2008: initial version by James Miller (not yet approved for publication)
+* September 8, 2008: initial version by "James Miller":credits.html#bensie (not yet approved for publication)
-- 
cgit v1.2.3


From 4f43c3c3ed283d0e32df5c0951ec09102c1b2f8b Mon Sep 17 00:00:00 2001
From: James Miller <james@jkmillertech.com>
Date: Fri, 5 Feb 2010 09:03:23 -0800
Subject: Correct command for installing/running bundler

---
 railties/guides/source/getting_started.textile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index c173748944..d7c9d39fd3 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -187,8 +187,8 @@ h4. Installing the Required Gems
 Rails uses the _Bundler_ gem to populate the +vendor+ directory with all the gems your application depends on.  As we don't need any special gems beyond the default, we just need to do the following:
 
 <shell>
-$ gem install bundle
-$ gem bundle
+$ gem install bundler
+$ bundle install
 </shell>
 
 This will copy down the latest versions of all the gems you need to start a rails application.
-- 
cgit v1.2.3


From b9e5263625a3e4f26c4bda3394f7425e148a0a6e Mon Sep 17 00:00:00 2001
From: Mikel Lindsaar <raasdnil@gmail.com>
Date: Mon, 8 Feb 2010 14:09:20 +1100
Subject: First pass at full re-write of getting started guide

 * Changed to Rails 3.0.0-beta rails command from script/*
 * Changed contrived before_filter to be an authentication feature
 * Refactored code into partials, showed three different types of partial usage
 * Showed how helpers work and fit in
---
 railties/guides/source/getting_started.textile | 801 +++++++++++++++----------
 1 file changed, 477 insertions(+), 324 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index d7c9d39fd3..fc3bf225e3 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -11,15 +11,15 @@ endprologue.
 
 WARNING. This Guide is based on Rails 3.0. Some of the code shown here will not work in other versions of Rails.
 
-h3. This Guide Assumes
+h3. Guide Assumptions
 
 This guide is designed for beginners who want to get started with a Rails application from scratch. It does not assume that you have any prior experience with Rails. However, to get the most out of it, you need to have some prerequisites installed:
 
 * The "Ruby":http://www.ruby-lang.org/en/downloads language version 1.8.7 or higher
 * The "RubyGems":http://rubyforge.org/frs/?group_id=126 packaging system
-* A working installation of "SQLite":http://www.sqlite.org (preferred), "MySQL":http://www.mysql.com, or "PostgreSQL":http://www.postgresql.org
+* A working installation of the "SQLite3 Database":http://www.sqlite.org
 
-It is highly recommended that you *familiarize yourself with Ruby before diving into Rails*. You will find it much easier to follow what's going on with a Rails application if you understand basic Ruby syntax. Rails isn't going to magically revolutionize the way you write web applications if you have no experience with the language it uses. There are some good free resources on the internet for learning Ruby, including:
+Rails is a web application framework running on the Ruby programming language. If you have no prior experience with Ruby, you will find a very steep learning curve diving straight into Rails.  There are some good free resources on the internet for learning Ruby, including:
 
 * "Mr. Neighborly's Humble Little Ruby Book":http://www.humblelittlerubybook.com
 * "Programming Ruby":http://www.ruby-doc.org/docs/ProgrammingRuby/
@@ -27,19 +27,19 @@ It is highly recommended that you *familiarize yourself with Ruby before diving
 
 h3. What is Rails?
 
-Rails is a web development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Longtime Rails developers also report that it makes web application development more fun.
+Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Experienced Rails developers also report that it makes web application development more fun.
 
-Rails is opinionated software. That is, it assumes that there is a best way to do things, and it's designed to encourage that best way - and in some cases to discourage alternatives. If you learn "The Rails Way" you'll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.
+Rails is opinionated software. It makes the assumption that there is a "best" way to do things, and it's designed to encourage that way - and in some cases to discourage alternatives. If you learn "The Rails Way" you'll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.
 
 The Rails philosophy includes several guiding principles:
 
 * DRY - "Don't Repeat Yourself" - suggests that writing the same code over and over again is a bad thing.
-* Convention Over Configuration - means that Rails makes assumptions about what you want to do and how you're going to do it, rather than letting you tweak every little thing through endless configuration files.
+* Convention Over Configuration - means that Rails makes assumptions about what you want to do and how you're going to do it, rather than requiring you to specify every little thing through endless configuration files.
 * REST is the best pattern for web applications - organizing your application around resources and standard HTTP verbs is the fastest way to go.
 
 h4. The MVC Architecture
 
-Rails is organized around the Model, View, Controller architecture, usually just called MVC. MVC benefits include:
+At the core of Rails is the Model, View, Controller architecture, usually just called MVC. MVC benefits include:
 
 * Isolation of business logic from the user interface
 * Ease of keeping code DRY
@@ -59,15 +59,23 @@ Controllers provide the "glue" between models and views. In Rails, controllers a
 
 h4. The Components of Rails
 
-Rails provides a full stack of components for creating web applications, including:
+Rails ships as many individual components.
 
-* Action Controller
-* Action View
-* Active Record
+* Action Pack
+  ** Action Controller
+  ** Action Dispatch
+  ** Action View
 * Action Mailer
+* Active Model
+* Active Record
 * Active Resource
-* Railties
 * Active Support
+* Railties
+
+
+h5. Action Pack
+
+Action Pack is a single gem that contains Action Controller, Action View and Action Dispatch.  The "VC" part of "MVC".
 
 h5. Action Controller
 
@@ -77,38 +85,46 @@ h5. Action View
 
 Action View manages the views of your Rails application. It can create both HTML and XML output by default. Action View manages rendering templates, including nested and partial templates, and includes built-in AJAX support.
 
-h5. Active Record
+h5. Action Dispatch
 
-Active Record is the base for the models in a Rails application. It provides database independence, basic CRUD functionality, advanced finding capabilities, and the ability to relate models to one another, among other services.
+Action Dispatch handles routing of web requests and dispatches them as you want, either to your application, any other Rack application.
 
 h5. Action Mailer
 
 Action Mailer is a framework for building e-mail services. You can use Action Mailer to send emails based on flexible templates, or to receive and process incoming email.
 
-h5. Active Resource
+h5. Active Model
 
-Active Resource provides a framework for managing the connection between business objects and RESTful web services. It implements a way to map web-based resources to local objects with CRUD semantics.
+Active Model provides a defined interface between the Action Pack gem services and Object Relationship Mapping gems such as Active Record.  Active Model allows Rails to utilize other ORM frameworks in place of Active Record if your application needs this.
 
-h5. Railties
+h5. Active Record
 
-Railties is the core Rails code that builds new Rails applications and glues the various frameworks and plugins together in any Rails application.
+Active Record is the base for the models in a Rails application. It provides database independence, basic CRUD functionality, advanced finding capabilities, and the ability to relate models to one another, among other services.
+
+h5. Active Resource
+
+Active Resource provides a framework for managing the connection between business objects and RESTful web services. It implements a way to map web-based resources to local objects with CRUD semantics.
 
 h5. Active Support
 
 Active Support is an extensive collection of utility classes and standard Ruby library extensions that are used in the Rails, both by the core code and by your applications.
 
+h5. Railties
+
+Railties is the core Rails code that builds new Rails applications and glues the various frameworks and plugins together in any Rails application.
+
 h4. REST
 
-The foundation of the RESTful architecture is generally considered to be Roy Fielding's doctoral thesis, "Architectural Styles and the Design of Network-based Software Architectures":http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Fortunately, you need not read this entire document to understand how REST works in Rails. REST, an acronym for Representational State Transfer, boils down to two main principles for our purposes:
+Rest stands for Representational State Transfer and is the foundation of the RESTful architecture. This is generally considered to be Roy Fielding's doctoral thesis, "Architectural Styles and the Design of Network-based Software Architectures":http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. While you can read through the thesis, REST in terms of Rails boils down to two main principles:
 
-* Using resource identifiers (which, for the purposes of discussion, you can think of as URLs) to represent resources
+* Using resource identifiers such as URLs to represent resources.
 * Transferring representations of the state of that resource between system components.
 
 For example, to a Rails application a request such as this:
 
 <tt>DELETE /photos/17</tt>
 
-would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities and browser quirks.
+would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails hooks into this shielding you from many of the RESTful complexities and browser quirks.
 
 If you'd like more details on REST as an architectural style, these resources are more approachable than Fielding's thesis:
 
@@ -126,33 +142,25 @@ h4. Installing Rails
 In most cases, the easiest way to install Rails is to take advantage of RubyGems:
 
 <shell>
-$ gem install rails
+Usually run this as the root user:
+# gem install rails
 </shell>
 
-NOTE. There are some special circumstances in which you might want to use an alternate installation strategy:
+NOTE. In the Rails 3.0.0-beta, you will need to manually install the dependencies for Rails itself as a bug in rubygems will cause these to not be installed, see the "3.0 Release Notes":http://guides.rails.info/3_0_release_notes.html for the commands to run.
 
-* If you're working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
-* If you want to keep up with cutting-edge changes to Rails, you'll want to clone the "Rails source code":http://github.com/rails/rails/tree/master from github. This is not recommended as an option for beginners, though.
+TIP. If you're working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
 
 h4. Creating the Blog Application
 
-Open a terminal, navigate to a folder where you have rights to create files, and type:
-
-<shell>
-$ rails blog
-</shell>
+The best way to use this guide is to follow each step as it happens, no code or step needed to make this example application has been left out, so you can literally follow along step by step.  If you need to see the completed code, you can download it from "Getting Started Code":http://github.com/mikel/getting-started-code.
 
-This will create a Rails application that uses a SQLite database for data storage. If you prefer to use MySQL, run this command instead:
+To begin, open a terminal, navigate to a folder where you have rights to create files, and type:
 
 <shell>
-$ rails blog -d mysql
+$ rails blog
 </shell>
 
-And if you're using PostgreSQL for data storage, run this command:
-
-<shell>
-$ rails blog -d postgresql
-</shell>
+This will create a Rails application called Blog in a directory called blog.
 
 TIP: You can see all of the switches that the Rails application builder accepts by running <tt>rails -h</tt>.
 
@@ -169,7 +177,6 @@ In any case, Rails will create a folder in your working directory called <tt>blo
 |README.rdoc|This is a brief instruction manual for your application. Use it to tell others what your application does, how to set it up, and so on.|
 |Rakefile|This file contains batch jobs that can be run from the terminal.|
 |app/|Contains the controllers, models, and views for your application. You'll focus on this folder for the remainder of this guide.|
-|bin/|Holds various executables needed for your Rails application.|
 |config/|Configure your application's runtime rules, routes, database, and more.|
 |config.ru|Rack configuration for Rack based servers used to start the application.|
 |db/|Shows your current database schema, as well as the database migrations. You'll learn about migrations shortly.|
@@ -177,54 +184,51 @@ In any case, Rails will create a folder in your working directory called <tt>blo
 |lib/|Extended modules for your application (not covered in this guide).|
 |log/|Application log files.|
 |public/|The only folder seen to the world as-is.  This is where your images, javascript, stylesheets (CSS), and other static files go.|
-|script/|Scripts provided by Rails to do recurring tasks, such as benchmarking, plugin installation, and starting the console or the web server.|
+|script/|Contains the rails script that starts your app and can contain other scripts you use to deploy or run your application.|
 |test/|Unit tests, fixtures, and other test apparatus. These are covered in "Testing Rails Applications":testing.html|
 |tmp/|Temporary files|
 |vendor/|A place for all third-party code. In a typical Rails application, this includes Ruby Gems, the Rails source code (if you install it into your project) and plugins containing additional prepackaged functionality.|
 
 h4. Installing the Required Gems
 
-Rails uses the _Bundler_ gem to populate the +vendor+ directory with all the gems your application depends on.  As we don't need any special gems beyond the default, we just need to do the following:
+Rails uses the "Bundler":http://www.github.com/carlhuda/bundler gem to populate the +vendor+ directory with all the gems your application depends on.  As we don't need any special gems beyond the default, we just need to do the following:
 
 <shell>
-$ gem install bundler
-$ bundle install
+As the root user:
+# gem install bundler
+# bundle install
 </shell>
 
-This will copy down the latest versions of all the gems you need to start a rails application.
+This will copy down the versions of all the gems you need to start a rails application.
 
 h4. Configuring a Database
 
 Just about every Rails application will interact with a database. The database to use is specified in a configuration file, +config/database.yml+.
-If you open this file in a new Rails application, you'll see a default database configuration using SQLite. The file contains sections for three different environments in which Rails can run by default:
+If you open this file in a new Rails application, you'll see a default database configuration using SQLite3. The file contains sections for three different environments in which Rails can run by default:
 
 * The +development+ environment is used on your development computer as you interact manually with the application
 * The +test+ environment is used to run automated tests
 * The +production+ environment is used when you deploy your application for the world to use.
 
-h5. Configuring a SQLite Database
+h5. Configuring a SQLite3 Database
 
-Rails comes with built-in support for "SQLite":http://www.sqlite.org, which is a lightweight serverless database application. While a busy production environment may overload SQLite, it works well for development and testing. Rails defaults to using a SQLite database when creating a new project, but you can always change it later.
+Rails comes with built-in support for "SQLite3":http://www.sqlite.org, which is a lightweight serverless database application. While a busy production environment may overload SQLite, it works well for development and testing. Rails defaults to using a SQLite database when creating a new project, but you can always change it later.
 
-Here's the section of the default configuration file with connection information for the development environment:
+Here's the section of the default configuration file (<tt>config/database.yml</tt>) with connection information for the development environment:
 
 <yaml>
 development:
-adapter: sqlite3
-database: db/development.sqlite3
-pool: 5
-timeout: 5000
+  adapter: sqlite3
+  database: db/development.sqlite3
+  pool: 5
+  timeout: 5000
 </yaml>
 
-If you don't have any database set up, SQLite is the easiest to get installed. If you're on OS X 10.5 or greater on a Mac, you already have it. Otherwise, you can install it using RubyGems:
-
-<shell>
-$ gem install sqlite3-ruby
-</shell>
+NOTE: In this guide we are using an SQLite3 database for data storage, this is because it is a zero configuration database that just works.  Rails also supports MySQL and PostgreSQL "out of the box", and has plugins for many database systems, if you are using a database in a production environment, Rails most likely has an adapter for it.
 
 h5. Configuring a MySQL Database
 
-If you choose to use MySQL, your +config/database.yml+ will look a little different. Here's the development section:
+If you choose to use MySQL instead of the shipped Sqlite3 database, your +config/database.yml+ will look a little different. Here's the development section:
 
 <yaml>
 development:
@@ -241,7 +245,7 @@ If your development computer's MySQL installation includes a root user with an e
 
 h5. Configuring a PostgreSQL Database
 
-If you choose to use PostgreSQL, your +config/database.yml+ will be customized to use PostgreSQL databases:
+Finally if you choose to use PostgreSQL, your +config/database.yml+ will be customized to use PostgreSQL databases:
 
 <yaml>
 development:
@@ -263,41 +267,39 @@ Now that you have your database configured, it's time to have Rails create an em
 $ rake db:create
 </shell>
 
-NOTE. Rake is a general-purpose command-runner that Rails uses for many things. You can see the list of available rake commands in your application by running +rake -T+.
+This will create your development and test SQLite3 databases inside the <tt>db/</tt> folder.
+
+TIP: Rake is a general-purpose command-runner that Rails uses for many things. You can see the list of available rake commands in your application by running +rake -T+.
 
 h3. Hello, Rails!
 
 One of the traditional places to start with a new language is by getting some text up on screen quickly, to do this, you need to get your Rails application server running.
 
-h4. Before we begin
-
-As an added help, you can find all the code of this application in a ready to run Git repository at "http://github.com/mikel/getting-started-code":http://github.com/mikel/getting-started-code.
-
 h4. Starting up the Web Server
 
-You actually have a functional Rails application already - after running only two commands! To see it, you need to start a web server on your development machine. You can do this by running another command:
+You actually have a functional Rails application already. To see it, you need to start a web server on your development machine. You can do this by running:
 
 <shell>
-$ script/server
+$ rails server
 </shell>
 
-This will fire up an instance of the Mongrel web server by default (Rails can also use several other web servers). To see your application in action, open a browser window and navigate to +http://localhost:3000+. You should see Rails' default information page:
+This will fire up an instance of the Mongrel web server by default (Rails can also use several other web servers). To see your application in action, open a browser window and navigate to "http://localhost:3000":http://localhost:3000. You should see Rails' default information page:
 
 !images/rails_welcome.png(Welcome Aboard screenshot)!
 
 TIP: To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to stop the server; changes you make in files will be automatically picked up by the server.
 
-The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page.  You can also click on the +About your application’s environment+ link to see a summary of your Application's environment.
+The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page.  You can also click on the _About your application’s environment_ link to see a summary of your Application's environment.
 
 h4. Say "Hello", Rails
 
 To get Rails saying "Hello", you need to create at minimum a controller and a view. Fortunately, you can do that in a single command. Enter this command in your terminal:
 
 <shell>
-$ script/generate controller home index
+$ rails generate controller home index
 </shell>
 
-TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
+TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +rails+ commands to Ruby: +ruby \path\to\rails controller home index+.
 
 Rails will create several files for you, including +app/views/home/index.html.erb+. This is the template that will be used to display the results of the +index+ action (method) in the +home+ controller. Open this file in your text editor and edit it to contain a single line of code:
 
@@ -307,7 +309,7 @@ Rails will create several files for you, including +app/views/home/index.html.er
 
 h4. Setting the Application Home Page
 
-Now that we have made the controller and view, we need to tell Rails when we want "Hello Rails" to show up.  In our case, we want it to show up when we navigate to the root URL of our site, +http://127.0.0.1:3000/+, instead of the "Welcome Aboard" smoke test.
+Now that we have made the controller and view, we need to tell Rails when we want "Hello Rails" to show up.  In our case, we want it to show up when we navigate to the root URL of our site, "http://localhost:3000":http://localhost:3000, instead of the "Welcome Aboard" smoke test.
 
 The first step to doing this is to delete the default page from your application:
 
@@ -331,7 +333,7 @@ Blog::Application.routes.draw do |map|
 
 The +root :to => "home#index"+ tells Rails to map the root action to the home controller's index action.
 
-Now if you navigate to +http://localhost:3000+ in your browser, you'll see +Hello, Rails!+.
+Now if you navigate to "http://localhost:3000":http://localhost:3000 in your browser, you'll see +Hello, Rails!+.
 
 NOTE. For more information about routing, refer to "Rails Routing from the Outside In":routing.html.
 
@@ -344,36 +346,36 @@ h3. Creating a Resource
 In the case of the blog application, you can start by generating a scaffolded Post resource: this will represent a single blog posting. To do this, enter this command in your terminal:
 
 <shell>
-$ script/generate scaffold Post name:string title:string content:text
+$ rails generate scaffold Post name:string title:string content:text
 </shell>
 
 NOTE. While scaffolding will get you up and running quickly, the "one size fits all" code that it generates is unlikely to be a perfect fit for your application. In most cases, you'll need to customize the generated code. Many experienced Rails developers avoid scaffolding entirely, preferring to write all or most of their source code from scratch.
 
-The scaffold generator will build 14 files in your application, along with some folders, and edit one more. Here's a quick overview of what it creates:
+The scaffold generator will build 15 files in your application, along with some folders, and edit one more. Here's a quick overview of what it creates:
 
 |_.File                                       |_.Purpose|
+|db/migrate/20100207214725_create_posts.rb.rb    |Migration to create the posts table in your database (your name will include a different timestamp)|
 |app/models/post.rb                           |The Post model|
-|db/migrate/20100123083454_create_posts.rb    |Migration to create the posts table in your database (your name will include a different timestamp)|
-|app/views/posts/index.html.erb|              |A view to display an index of all posts |
+|test/unit/post_test.rb                       |Unit testing harness for the posts model|
+|test/fixtures/posts.yml                      |Dummy posts for use in testing|
+|app/controllers/posts_controller.rb          |The Posts controller|
+|app/views/posts/index.html.erb               |A view to display an index of all posts |
 |app/views/posts/edit.html.erb                |A view to edit an existing post|
 |app/views/posts/show.html.erb                |A view to display a single post|
 |app/views/posts/new.html.erb                 |A view to create a new post|
 |app/views/posts/_form.html.erb               |A view to control the overall look and feel of the other posts views|
 |app/views/layouts/posts.html.erb             |A view to control the overall look and feel of the other posts views|
-|public/stylesheets/scaffold.css              |Cascading style sheet to make the scaffolded views look better|
-|app/controllers/posts_controller.rb          |The Posts controller|
 |test/functional/posts_controller_test.rb     |Functional testing harness for the posts controller|
 |app/helpers/posts_helper.rb                  |Helper functions to be used from the posts views|
 |config/routes.rb                             |Edited to include routing information for posts|
-|test/fixtures/posts.yml                      |Dummy posts for use in testing|
-|test/unit/post_test.rb                       |Unit testing harness for the posts model|
 |test/unit/helpers/posts_helper_test.rb       |Unit testing harness for the posts helper|
+|public/stylesheets/scaffold.css              |Cascading style sheet to make the scaffolded views look better|
 
 h4. Running a Migration
 
-One of the products of the +script/generate scaffold+ command is a _database migration_. Migrations are Ruby classes that are designed to make it simple to create and modify database tables. Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database. Migration filenames include a timestamp to ensure that they're processed in the order that they were created.
+One of the products of the +rails generate scaffold+ command is a _database migration_. Migrations are Ruby classes that are designed to make it simple to create and modify database tables. Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database. Migration filenames include a timestamp to ensure that they're processed in the order that they were created.
 
-If you look in the +db/migrate/20100123083454_create_posts.rb+ file (remember, yours will have a slightly different name), here's what you'll find:
+If you look in the +db/migrate/20100207214725_create_posts.rb+ file (remember, yours will have a slightly different name), here's what you'll find:
 
 <ruby>
 class CreatePosts < ActiveRecord::Migration
@@ -393,7 +395,7 @@ class CreatePosts < ActiveRecord::Migration
 end
 </ruby>
 
-If you were to translate that into words, it says something like: when this migration is run, create a table named +posts+ with two string columns (+name+ and +title+) and a text column (+content+), and generate timestamp fields to track record creation and updating. You can learn the detailed syntax for migrations in the "Rails Database Migrations":migrations.html guide.
+The above migration creates two methods, +up+, called when you run this migration into the database, and +down+ in case you need to reverse the changes made by this migration at a later date.  The +up+ command in this case creates a +posts+ table with two string columns and a text column.  It also is creating two timestamp fields to track record creation and updating.  More information about Rails migrations can be found in the "Rails Database Migrations":migrations.html guide.
 
 At this point, you can use a rake command to run the migration:
 
@@ -401,15 +403,13 @@ At this point, you can use a rake command to run the migration:
 $ rake db:migrate
 </shell>
 
-Remember, you can't run migrations before running +rake db:create+ to create your database, as we covered earlier.
-
-Rails will execute this migration command and tell you is created the Posts table.
+Rails will execute this migration command and tell you it created the Posts table.
 
 <shell>
-==  CreatePosts: migrating =================================================
+==  CreatePosts: migrating ====================================================
 -- create_table(:posts)
    -> 0.0019s
-==  CreatePosts: migrated (0.0020s) ========================================
+==  CreatePosts: migrated (0.0020s) ===========================================
 </shell>
 
 NOTE. Because you're working in the development environment by default, this command will apply to the database defined in the +development+ section of your +config/database.yml+ file.
@@ -427,7 +427,7 @@ The +link_to+ method is one of Rails' built-in view helpers. It creates a hyperl
 
 h4. Working with Posts in the Browser
 
-Now you're ready to start working with posts. To do that, navigate to +http://localhost:3000+ and then click the "My Blog" link:
+Now you're ready to start working with posts. To do that, navigate to "http://localhost:3000":http://localhost:3000/ and then click the "My Blog" link:
 
 !images/posts_index.png(Posts Index screenshot)!
 
@@ -467,21 +467,22 @@ h4. Using the Console
 To see your validations in action, you can use the console. The console is a command-line tool that lets you execute Ruby code in the context of your application:
 
 <shell>
-$ script/console
+$ rails console
 </shell>
 
 After the console loads, you can use it to work with your application's models:
 
 <shell>
 >> p = Post.create(:content => "A new post")
-=> #<Post id: nil, name: nil, title: nil, content: "A new post",
-created_at: nil, updated_at: nil>
+=> #<Post id: nil, name: nil, title: nil, 
+     content: "A new post", created_at: nil,
+     updated_at: nil>
 >> p.save
 => false
 >> p.errors
-=> #<OrderedHash {:title=>["can't be blank", 
-                  "is too short (minimum is 5 characters)"],
-                  :name=>["can't be blank"]}>
+=> #<OrderedHash { :title=>["can't be blank", 
+                           "is too short (minimum is 5 characters)"],
+                   :name=>["can't be blank"] }>
 </shell>
 
 This code shows creating a new +Post+ instance, attempting to save it and getting +false+ for a return value (indicating that the save failed), and inspecting the +errors+ of the post.
@@ -507,7 +508,7 @@ This code sets the +@posts+ instance variable to an array of all posts in the da
 
 TIP: For more information on finding records with Active Record, see "Active Record Query Interface":active_record_querying.html.
 
-The +respond_to+ block handles both HTML and XML calls to this action. If you browse to +http://localhost:3000/posts.xml+, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/views/posts/index.html.erb+:
+The +respond_to+ block handles both HTML and XML calls to this action. If you browse to "http://localhost:3000/posts.xml":http://localhost:3000/posts.xml, you'll see all of the posts in XML format. The HTML format looks for a view in +app/views/posts/+ with a name that corresponds to the action name. Rails makes all of the instance variables from the action available to the view. Here's +app/views/posts/index.html.erb+:
 
 <erb>
 <h1>Listing posts</h1>
@@ -550,7 +551,7 @@ TIP: For more details on the rendering process, see "Layouts and Rendering in Ra
 
 h4. Customizing the Layout
 
-The view is only part of the story of how HTML is displayed in your web browser. Rails also has the concept of +layouts+, which are containers for views. When Rails renders a view to the browser, it does so by putting the view's HTML into a layout's HTML. The +script/generate scaffold+ command automatically created a default layout, +app/views/layouts/posts.html.erb+, for the posts. Open this layout in your editor and modify the +body+ tag:
+The view is only part of the story of how HTML is displayed in your web browser. Rails also has the concept of +layouts+, which are containers for views. When Rails renders a view to the browser, it does so by putting the view's HTML into a layout's HTML. The +rails generate scaffold+ command automatically created a default layout, +app/views/layouts/posts.html.erb+, for the posts. Open this layout in your editor and modify the +body+ tag:
 
 <erb>
 <!DOCTYPE html>
@@ -596,7 +597,7 @@ The +new.html.erb+ view displays this empty Post to the user:
 <%= link_to 'Back', posts_path %>
 </erb>
 
-The +<%= render 'form' %>+ line is our first introduction to _partials_ in Rails.  A partial is a snippet of HTML and Ruby code that can be reused in multiple locations.  In this case, the form used to make a new post, is very similar to a form used to edit a post, both have text fields for the name and title and a text area for the content with a button to make a new post or update the existing post.
+The +<%= render 'form' %>+ line is our first introduction to _partials_ in Rails.  A partial is a snippet of HTML and Ruby code that can be reused in multiple locations.  In this case, the form used to make a new post, is basically identical to a form used to edit a post, both have text fields for the name and title and a text area for the content with a button to make a new post or update the existing post.
 
 If you take a look at +views/posts/_form.html.erb+ file, you will see the following:
 
@@ -761,71 +762,6 @@ end
 
 The +destroy+ method of an Active Record model instance removes the corresponding record from the database. After that's done, there isn't any record to display, so Rails redirects the user's browser to the index view for the model.
 
-h3. DRYing up the Code
-
-At this point, it's worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views (as you saw above with the +new+ and +edit+ views both sharing the +form+ partial) and _filters_ to help with duplication in controllers.
-
-h4. Using Filters to Eliminate Controller Duplication
-
-At this point, if you look at the controller for posts, you'll see some duplication:
-
-<ruby>
-class PostsController < ApplicationController
-  # ...
-  def show
-    @post = Post.find(params[:id])
-  # ...
-  end
-
-  def edit
-    @post = Post.find(params[:id])
-  end
-
-  def update
-    @post = Post.find(params[:id])
-    # ...
-  end
-
-  def destroy
-    @post = Post.find(params[:id])
-    # ...
-  end
-end
-</ruby>
-
-Four instances of the exact same line of code doesn't seem very DRY. Rails provides _filters_ as a way to address this sort of repeated code. In this case, you can DRY things up by using a +before_filter+:
-
-<ruby>
-class PostsController < ApplicationController
-  before_filter :find_post,
-    :only => [:show, :edit, :update, :destroy]
-  # ...
-  def show
-  # ...
-  end
-
-  def edit
-  end
-
-  def update
-    # ...
-  end
-
-  def destroy
-    # ...
-  end
-
-private
-  def find_post
-    @post = Post.find(params[:id])
-  end
-end
-</ruby>
-
-Rails runs _before filters_ before any action in the controller. You can use the +:only+ clause to limit a before filter to only certain actions, or an +:except+ clause to specifically skip a before filter for certain actions. Rails also allows you to define _after filters_ that run after processing an action, as well as _around filters_ that surround the processing of actions. Filters can also be defined in external classes to make it easy to share them between controllers.
-
-For more information on filters, see the "Action Controller Overview":action_controller_overview.html guide.
-
 h3. Adding a Second Model
 
 Now that you've seen what's in a model built with scaffolding, it's time to add a second model to the application. The second model will handle comments on blog posts.
@@ -835,13 +771,13 @@ h4. Generating a Model
 Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:
 
 <shell>
-$ script/generate model Comment commenter:string body:text  post:references
+$ rails generate model Comment commenter:string body:text post:references
 </shell>
 
 This command will generate four files:
 
 * +app/models/comment.rb+ - The model
-* +db/migrate/20100124023310_create_comments.rb+ - The migration
+* +db/migrate/20100207235629_create_comments.rb+ - The migration
 * +test/unit/comment_test.rb+ and +test/fixtures/comments.yml+ - The test harness.
 
 First, take a look at +comment.rb+:
@@ -885,8 +821,8 @@ Rails is smart enough to only execute the migrations that have not already been
 <shell>
 ==  CreateComments: migrating =================================================
 -- create_table(:comments)
-   -> 0.0019s
-==  CreateComments: migrated (0.0020s) ========================================
+   -> 0.0017s
+==  CreateComments: migrated (0.0018s) ========================================
 </shell>
 
 h4. Associating Models
@@ -911,6 +847,7 @@ class Post < ActiveRecord::Base
   validates :name,  :presence => true
   validates :title, :presence => true,
                     :length => { :minimum => 5 }
+
   has_many :comments
 end
 </ruby>
@@ -938,164 +875,173 @@ h4. Generating a Controller
 With the model in hand, you can turn your attention to creating a matching controller. Again, there's a generator for this:
 
 <shell>
-$ script/generate controller Comments index show new edit
+$ rails generate controller Comments
 </shell>
 
-This creates eight files:
+This creates four files:
 
 * +app/controllers/comments_controller.rb+ - The controller
 * +app/helpers/comments_helper.rb+ - A view helper file
-* +app/views/comments/index.html.erb+ - The view for the index action
-* +app/views/comments/show.html.erb+ - The view for the show action
-* +app/views/comments/new.html.erb+ - The view for the new action
-* +app/views/comments/edit.html.erb+ - The view for the edit action
 * +test/functional/comments_controller_test.rb+ - The functional tests for the controller
 * +test/unit/helpers/comments_helper_test.rb+ - The unit tests for the helper
 
-The controller will be generated with empty methods and views for each action that you specified in the call to +script/generate controller+:
+Like with any blog, our readers will create their comments directly after reading the post, and once they have added their comment, will be sent back to the post show page to see their comment now listed.  Due to this, our +CommentsController+ is there to provide a method to create comments and delete SPAM comments when they arrive.
 
-<ruby>
-class CommentsController < ApplicationController
-  def index
-  end
-
-  def show
-  end
-
-  def new
-  end
+So first, we'll wire up the Post show template (+/app/views/posts/show.html.erb+) to let us make a new comment:
 
-  def edit
-  end
+<erb>
+<p>
+  <b>Name:</b>
+  <%= @post.name %>
+</p>
 
-end
-</ruby>
+<p>
+  <b>Title:</b>
+  <%= @post.title %>
+</p>
 
-You'll need to flesh this out with code to actually process requests appropriately in each method. Here's a version that (for simplicity's sake) only responds to requests that require HTML:
+<p>
+  <b>Content:</b>
+  <%= @post.content %>
+</p>
 
-<ruby>
-class CommentsController < ApplicationController
-  before_filter :find_post
+<h2>Add a comment:</h2>
+<% form_for([@post, @post.comments.build]) do |f| %>
+  <%= f.error_messages %>
 
-  def index
-    @comments = @post.comments
-  end
+  <div class="field">
+    <%= f.label :commenter %><br />
+    <%= f.text_field :commenter %>
+  </div>
+  <div class="field">
+    <%= f.label :body %><br />
+    <%= f.text_area :body %>
+  </div>
+  <div class="actions">
+    <%= f.submit %>
+  </div>
+<% end %>
 
-  def show
-    @comment = @post.comments.find(params[:id])
-  end
+<%= link_to 'Edit Post', edit_post_path(@post) %> |
+<%= link_to 'Back to Posts', posts_path %> |
+</erb>
 
-  def new
-    @comment = @post.comments.build
-  end
+This adds a form on the Post show page that creates a new comment, which will call the +CommentsController+ +create+ action, so let's wire that up:
 
+<ruby>
+class CommentsController < ApplicationController
   def create
-    @comment = @post.comments.build(params[:comment])
-    if @comment.save
-      redirect_to post_comment_url(@post, @comment)
-    else
-      render :action => "new"
-    end
-  end
-
-  def edit
-    @comment = @post.comments.find(params[:id])
-  end
-
-  def update
-    @comment = Comment.find(params[:id])
-    if @comment.update_attributes(params[:comment])
-      redirect_to post_comment_url(@post, @comment)
-    else
-      render :action => "edit"
-    end
-  end
-
-  def destroy
-    @comment = Comment.find(params[:id])
-    @comment.destroy
-    redirect_to post_comments_path(@post)
-  end
-
-private
-  def find_post
     @post = Post.find(params[:post_id])
+    @comment = @post.comments.create(params[:comment])
+    redirect_to post_path(@post)
   end
-
 end
 </ruby>
 
-You'll see a bit more complexity here than you did in the controller for posts. That's a side-effect of the nesting that you've set up; each request for a comment has to keep track of the post to which the comment is attached.
+You'll see a bit more complexity here than you did in the controller for posts. That's a side-effect of the nesting that you've set up; each request for a comment has to keep track of the post to which the comment is attached, thus the initial find action to the Post model to get the post in question.
 
 In addition, the code takes advantage of some of the methods available for an association. For example, in the +new+ method, it calls
 
-<ruby>
-@comment = @post.comments.build
-</ruby>
+Once we have made the new comment, we send the user back to the +post_path(@post)+ URL.  This runs the +show+ action of the +PostsController+ which then renders the +show.html.erb+ template where we want the comment to show, so then, we'll add that to the +app/view/posts/show.html.erb+.
 
-This creates a new +Comment+ object _and_ sets up the +post_id+ field to have the +id+ from the specified +Post+ object in a single operation.
+<erb>
+<p>
+  <b>Name:</b>
+  <%= @post.name %>
+</p>
 
-h4. Building Views
+<p>
+  <b>Title:</b>
+  <%= @post.title %>
+</p>
 
-Because you skipped scaffolding, you'll need to build views for comments "by hand". Invoking +script/generate controller+ will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.
+<p>
+  <b>Content:</b>
+  <%= @post.content %>
+</p>
 
-The +views/comments/index.html.erb+ view:
+<h2>Comments</h2>
+<% @post.comments.each do |comment| %>
+  <p>
+    <b>Commenter:</b>
+    <%= comment.commenter %>
+  </p>
 
-<erb>
-<h1>Comments for <%= @post.title %></h1>
+  <p>
+    <b>Comment:</b>
+    <%= comment.body %>
+  </p>
+<% end %>
 
-<table>
-  <tr>
-    <th>Commenter</th>
-    <th>Body</th>
-    <th></th>
-    <th></th>
-    <th></th>
-  </tr>
+<h2>Add a comment:</h2>
+<% form_for([@post, @post.comments.build]) do |f| %>
+  <%= f.error_messages %>
 
-<% @comments.each do |comment| %>
-  <tr>
-    <td><%= comment.commenter %></td>
-    <td><%= comment.body %></td>
-    <td><%= link_to 'Show', post_comment_path(@post, comment) %></td>
-    <td><%= link_to 'Edit', edit_post_comment_path(@post, comment) %></td>
-    <td><%= link_to 'Destroy', post_comment_path(@post, comment), 
-                    :confirm => 'Are you sure?', :method => :delete %></td>
-  </tr>
+  <div class="field">
+    <%= f.label :commenter %><br />
+    <%= f.text_field :commenter %>
+  </div>
+  <div class="field">
+    <%= f.label :body %><br />
+    <%= f.text_area :body %>
+  </div>
+  <div class="actions">
+    <%= f.submit %>
+  </div>
 <% end %>
-</table>
 
 <br />
 
-<%= link_to 'New comment', new_post_comment_path(@post) %>
-<%= link_to 'Back to Post', @post %>
+<%= link_to 'Edit Post', edit_post_path(@post) %> |
+<%= link_to 'Back to Posts', posts_path %> |
 </erb>
 
-The +views/comments/new.html.erb+ view (again using a partial to render a form that is shared with the +edit+ view):
+Now you can add posts and comments to your blog and have them show up in the right places.
 
-<erb>
-<h1>New comment</h1>
+h3. Refactorization
 
-<%= render 'form' %>
+Now that we have Posts and Comments working, we can take a look at the +app/views/posts/show.html.erb+ template, it is getting long and awkward, we can use partials to clean this up.
 
-<%= link_to 'Back', post_comments_path(@post) %>
-</erb>
+h4. Rendering Partial Collections
 
-The +views/comments/edit.html.erb+ view:
+First will make a comment partial to extract showing all the comments for the post, so make a file +app/views/comments/_comment.html.erb+ and put into it:
 
 <erb>
-<h1>Editing comment</h1>
-
-<%= render 'form' %>
+<p>
+  <b>Commenter:</b>
+  <%= comment.commenter %>
+</p>
 
-<%= link_to 'Show', post_comment_path(@post, @comment) %> |
-<%= link_to 'Back', post_comments_path(@post) %>
+<p>
+  <b>Comment:</b>
+  <%= comment.body %>
+</p>
 </erb>
 
-The +views/comments/_form.html.erb+ partial:
+Then in the +app/views/posts/show.html.erb+ you can change it to look like the following:
 
 <erb>
-<% form_for([@post, @comment]) do |f| %>
+<p>
+  <b>Name:</b>
+  <%= @post.name %>
+</p>
+
+<p>
+  <b>Title:</b>
+  <%= @post.title %>
+</p>
+
+<p>
+  <b>Content:</b>
+  <%= @post.content %>
+</p>
+
+<h2>Comments</h2>
+<%= render :partial => "comments/comment", 
+           :collection => @post.comments %>
+
+<h2>Add a comment:</h2>
+<% form_for([@post, @post.comments.build]) do |f| %>
   <%= f.error_messages %>
 
   <div class="field">
@@ -1110,32 +1056,38 @@ The +views/comments/_form.html.erb+ partial:
     <%= f.submit %>
   </div>
 <% end %>
-</erb>
 
-The +views/comments/show.html.erb+ view:
+<br />
 
-<erb>
-<h1>Comment on <%= @post.title %></h1>
+<%= link_to 'Edit Post', edit_post_path(@post) %> |
+<%= link_to 'Back to Posts', posts_path %> |
+</erb>
 
-<p>
-  <b>Commenter:</b>
-  <%= @comment.commenter %>
-</p>
+This will now render the partial in +app/views/comments/_comment.html.erb+ once for each comment that is in the +@post.comments+ collection.  As the +render+ method iterates over the <tt>@post.comments</tt> collection, it assigns each comment to a local variable named the same as the partial, in this case +comment+ which is then available in the partial for us to show.
 
-<p>
-  <b>Comment:</b>
-  <%= @comment.body %>
-</p>
+h4. Rendering a Partial Form
 
-<%= link_to 'Edit', edit_post_comment_path(@post, @comment) %> |
-<%= link_to 'Back', post_comments_path(@post) %>
-</erb>
+Lets also move that new comment section out to it's own partial, again, you create a file +app/views/comments/_form.html.erb+ and in it you put:
 
-Again, the added complexity here (compared to the views you saw for managing posts) comes from the necessity of juggling a post and its comments at the same time.
+<erb>
+<% form_for([@post, @post.comments.build]) do |f| %>
+  <%= f.error_messages %>
 
-h4. Hooking Comments to Posts
+  <div class="field">
+    <%= f.label :commenter %><br />
+    <%= f.text_field :commenter %>
+  </div>
+  <div class="field">
+    <%= f.label :body %><br />
+    <%= f.text_area :body %>
+  </div>
+  <div class="actions">
+    <%= f.submit %>
+  </div>
+<% end %>
+</erb>
 
-As a next step, I'll modify the +views/posts/show.html.erb+ view to show the comments on that post, and to allow managing those comments:
+Then you make the +app/views/posts/show.html.erb+ look like the following:
 
 <erb>
 <p>
@@ -1154,24 +1106,69 @@ As a next step, I'll modify the +views/posts/show.html.erb+ view to show the com
 </p>
 
 <h2>Comments</h2>
-<% @post.comments.each do |comment| %>
-  <p>
-    <b>Commenter:</b>
-    <%= comment.commenter %>
-  </p>
+<%= render :partial => "comments/comment", 
+           :collection => @post.comments %>
 
-  <p>
-    <b>Comment:</b>
-    <%= comment.body %>
-  </p>
-<% end %>
+<h2>Add a comment:</h2>
+<%= render "comments/form" %>
+
+<br />
 
 <%= link_to 'Edit Post', edit_post_path(@post) %> |
 <%= link_to 'Back to Posts', posts_path %> |
-<%= link_to 'Manage Comments', post_comments_path(@post) %>
 </erb>
 
-Note that each post has its own individual comments collection, accessible as +@post.comments+. That's a consequence of the declarative associations in the models. Path helpers such as +post_comments_path+ come from the nested route declaration in +config/routes.rb+.
+The second render just defines the partial template we want to render, <tt>comments/form</tt>, Rails is smart enough to spot the forward slash in that string and realise that you want to render the <tt>_form.html.erb</tt> file in the <tt>app/views/comments</tt> directory.
+
+The +@post+ object is available any partials rendered in the view because we defined it as an instance variable.
+
+h3. Deleting Comments
+
+Another important feature on a blog is being able to delete SPAM comments.  To do this, we need to implement a link of some sort in the view and a +DELETE+ action in the +CommentsController+.
+
+So first, let's add the delete link in the +app/views/comments/_comment.html.erb+ partial:
+
+<erb>
+<p>
+  <b>Commenter:</b>
+  <%= comment.commenter %>
+</p>
+
+<p>
+  <b>Comment:</b>
+  <%= comment.body %>
+</p>
+
+<p>
+  <%= link_to 'Destroy Comment', [comment.post, comment],
+               :confirm => 'Are you sure?',
+               :method => :delete %>
+</p>
+</erb>
+
+Clicking this new "Destroy Comment" link will fire off a <tt>DELETE /posts/:id/comments/:id</tt> to our +CommentsController+, which can then use this to find the comment we want to delete, so let's add a destroy action to our controller:
+
+<ruby>
+class CommentsController < ApplicationController
+
+  def create
+    @post = Post.find(params[:post_id])
+    @comment = @post.comments.create(params[:comment])
+    redirect_to post_path(@post)
+  end
+
+  def destroy
+    @post = Post.find(params[:post_id])
+    @comment = @post.comments.find(params[:id])
+    @comment.destroy
+    redirect_to post_path(@post)
+  end
+
+end
+</ruby>
+
+The +destroy+ action will find the post we are looking at, locate the comment within the <tt>@post.comments</tt> collection, and then remove it from the database and send us back to the show action for the post.
+
 
 h4. Deleting Associated Objects
 
@@ -1184,14 +1181,73 @@ class Post < ActiveRecord::Base
                     :length => { :minimum => 5 }
   has_many :comments, :dependent => :destroy
 end
-</ruby> 
+</ruby>
+
+h3. Security
+
+Before you publish your blog online, you will most likely want to prevent just anyone from being able to add, edit and delete posts or delete comments.
+
+Rails provides a very simple http authentication system that will work nicely in this situation.  First, we enable simple HTTP based authentication in our <tt>app/controllers/application_controller.rb</tt>:
+
+<ruby>
+class ApplicationController < ActionController::Base
+  protect_from_forgery
+  
+  private
+  
+  def authenticate
+    authenticate_or_request_with_http_basic do |user_name, password|
+      user_name == 'admin' && password == 'password'
+    end
+  end
+  
+end
+</ruby>
+
+You can obviously change the username and password to whatever you want.  We put this method inside of +ApplicationController+ so that it is available to all of our controllers.
+
+Then in the +PostsController+ we need to have a way to block access to the various actions if the person is not authenticated, here we can use the Rails <tt>before_filter</tt> method, which allows us to specify that Rails must run a method and only then allow access to the requested action if that method allows it.
+
+To use the before filter, we specify it at the top of our +PostsController+, in this case, we want the user to be authenticated on every action, except for +index+ and +show+, so we write that:
+
+<ruby>
+class PostsController < ApplicationController
+
+  before_filter :authenticate, :except => [:index, :show]
+
+  # GET /posts
+  # GET /posts.xml
+  def index
+    @posts = Post.all
+    respond_to do |format|
+# snipped for brevity
+</ruby>
+
+We also only want to allow authenticated users to delete comments, so in the +CommentsController+ we write:
+
+<ruby>
+class CommentsController < ApplicationController
+
+  before_filter :authenticate, :only => :destroy
+
+  def create
+    @post = Post.find(params[:post_id])
+# snipped for brevity
+</ruby>
+
+Now if you try to create a new post, you will be greeted with a basic HTTP Authentication challenge
+
+!images/challenge.png(Basic HTTP Authentication Challenge)!
+
 
 h3. Building a Multi-Model Form
 
-Comments and posts are edited on two separate forms - which makes sense, given the flow of this mini-application. But what if you want to edit more than one thing on a single form? Rails offers support for nested forms. Let's add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
+Another piece of your average blog is the ability to tag posts.  This requires that your application edits more than one thing on a single form.  Rails offers support for nested forms.
+
+To demonstrate this, we will add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
 
 <shell>
-$ script/generate model tag name:string post:references
+$ rails generate model tag name:string post:references
 </shell>
 
 Again, run the migration to create the database table:
@@ -1207,7 +1263,8 @@ class Post < ActiveRecord::Base
   validates :name,  :presence => true
   validates :title, :presence => true,
                     :length => { :minimum => 5 }
-  has_many :comments
+
+  has_many :comments, :dependent => :destroy
   has_many :tags
 
   accepts_nested_attributes_for :tags, :allow_destroy => :true,
@@ -1217,7 +1274,7 @@ end
 
 The +:allow_destroy+ option on the nested attribute declaration tells Rails to display a "remove" checkbox on the view that you'll build shortly. The +:reject_if+ option prevents saving new tags that do not have any attributes filled in.
 
-You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
+We will modify +views/posts/_form.html.erb+ to render a partial to make a tag:
 
 <erb>
 <% @post.tags.build %>
@@ -1237,30 +1294,124 @@ You'll also need to modify +views/posts/_form.html.erb+ to include the tags:
     <%= post_form.text_area :content %>
   </div>
   <h2>Tags</h2>
-  <% post_form.fields_for :tags do |tag_form| %>
-    <div class="field">
-      <%= tag_form.label :name, 'Tag:' %>
-      <%= tag_form.text_field :name %>
-    </div>
-    <% unless tag_form.object.nil? || tag_form.object.new_record? %>
-      <div class="field">
-        <%= tag_form.label :_destroy, 'Remove:' %>
-        <%= tag_form.check_box :_destroy %>
-      </div>
-    <% end %>
-  <% end %>
-
+  <%= render :partial => 'tags/form',
+             :locals => {:form => post_form} %>
   <div class="actions">
     <%= post_form.submit %>
   </div>
 <% end %>
 </erb>
 
-You will note that we also have changed the +form_for(@post) do |f|+ to +form_for(@post) do |post_form|+ and changed all the +f+ method calls as well to show more clearly what is going on.
+This example shows another option of the render helper, being able to pass in local variables, in this case, we want the local variable +form+ in the partial to refer to the +post_form+ object.
+
+You will also note that we also have changed the +f+ in <tt>form_for(@post) do |f|</tt> to <tt>post_form</tt> to clarify what is going on somewhat.
+
+We also add a <tt>@post.tags.build</tt> at the top of this form, this is to make sure there is a new tag ready to have it's name filled in by the user.  If you do not build the new tag, then the form will not appear as there is no new Tag object ready to create.
+
+Now create the folder <tt>app/views/tags</tt> and make a file in there called <tt>_form.html.erb</tt> which contains the form for the tag:
+
+<erb>
+<% form.fields_for :tags do |tag_form| %>
+  <div class="field">
+    <%= tag_form.label :name, 'Tag:' %>
+    <%= tag_form.text_field :name %>
+  </div>
+  <% unless tag_form.object.nil? || tag_form.object.new_record? %>
+    <div class="field">
+      <%= tag_form.label :_destroy, 'Remove:' %>
+      <%= tag_form.check_box :_destroy %>
+    </div>
+  <% end %>
+<% end %>
+</erb>
+
+Finally, we will edit the <tt>app/views/posts/show.html.erb</tt> template to show our tags.
+
+<erb>
+<p>
+  <b>Name:</b>
+  <%= @post.name %>
+</p>
+
+<p>
+  <b>Title:</b>
+  <%= @post.title %>
+</p>
+
+<p>
+  <b>Content:</b>
+  <%= @post.content %>
+</p>
+
+<p>
+  <b>Tags:</b>
+  <%= @post.tags.map { |t| t.name }.join(", ") %>
+</p>
+
+<h2>Comments</h2>
+<%= render :partial => "comments/comment", 
+           :collection => @post.comments %>
+
+<h2>Add a comment:</h2>
+<%= render "comments/form" %>
+
+
+<%= link_to 'Edit Post', edit_post_path(@post) %> |
+<%= link_to 'Back to Posts', posts_path %> |
+</erb>
 
 With these changes in place, you'll find that you can edit a post and its tags directly on the same view.
 
-NOTE. You may want to use JavaScript to dynamically add additional tags on a single form. For an example of this and other advanced techniques, see the "complex form examples application":http://github.com/mikel/complex-form-examples/.
+However, that method call <tt>@post.tags.map { |t| t.name }.join(", ")</tt> is awkward, we could handle this by making a helper method.
+
+h3. View Helpers
+
+View Helpers live in <tt>app/helpers</tt> and provide small snippets of reusable code for views.  In our case, we want a method that strings a bunch of objects together using their name attribute and joining them with a comma.  As this is for the Post show template, we put it in the PostsHelper.
+
+Open up <tt>app/helpers/posts_helper.rb</tt> and add the following:
+
+<erb>
+module PostsHelper
+  def join_tags(post)
+    post.tags.map { |t| t.name }.join(", ") 
+  end
+end
+</erb>
+
+Now you can edit the view in <tt>app/views/posts/show.html.erb</tt> to look like this:
+
+<erb>
+<p>
+  <b>Name:</b>
+  <%= @post.name %>
+</p>
+
+<p>
+  <b>Title:</b>
+  <%= @post.title %>
+</p>
+
+<p>
+  <b>Content:</b>
+  <%= @post.content %>
+</p>
+
+<p>
+  <b>Tags:</b>
+  <%= join_tags(@post) %>
+</p>
+
+<h2>Comments</h2>
+<%= render :partial => "comments/comment", 
+           :collection => @post.comments %>
+
+<h2>Add a comment:</h2>
+<%= render "comments/form" %>
+
+
+<%= link_to 'Edit Post', edit_post_path(@post) %> |
+<%= link_to 'Back to Posts', posts_path %> |
+</erb>
 
 h3. What's Next?
 
@@ -1276,10 +1427,12 @@ Rails also comes with built-in help that you can generate using the rake command
 * Running +rake doc:guides+ will put a full copy of the Rails Guides in the +doc/guides+ folder of your application. Open +doc/guides/index.html+ in your web browser to explore the Guides.
 * Running +rake doc:rails+ will put a full copy of the API documentation for Rails in the +doc/api+ folder of your application. Open +doc/api/index.html+ in your web browser to explore the API documentation.
 
+
 h3. Changelog
 
 "Lighthouse ticket":http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2
 
+* February 8, 2010: Full re-write for Rails 3.0-beta, added helpers and before_filters, refactored code by "Mikel Lindsaar":credits:html#raasdnil
 * January 24, 2010: Re-write for Rails 3.0 by "Mikel Lindsaar":credits:html#raasdnil
 * July 18, 2009: Minor cleanup in anticipation of Rails 2.3.3 by "Mike Gunderloy":credits.html#mgunderloy
 * February 1, 2009: Updated for Rails 2.3 by "Mike Gunderloy":credits.html#mgunderloy
-- 
cgit v1.2.3


From 6a6644742f81b1f7a8b8f35f43873bbf8827f1f1 Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Mon, 8 Feb 2010 09:40:37 +0100
Subject: getting started guide: move link to Instant Rails to the first
 occurrence

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index fc3bf225e3..f0488ddc90 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -148,7 +148,7 @@ Usually run this as the root user:
 
 NOTE. In the Rails 3.0.0-beta, you will need to manually install the dependencies for Rails itself as a bug in rubygems will cause these to not be installed, see the "3.0 Release Notes":http://guides.rails.info/3_0_release_notes.html for the commands to run.
 
-TIP. If you're working on Windows, you may find it easier to install Instant Rails. Be aware, though, that "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
+TIP. If you're working on Windows, you may find it easier to install "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl. Be aware, though, that Instant Rails releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
 
 h4. Creating the Blog Application
 
-- 
cgit v1.2.3


From 50b3040115a386acb5e68235c46c7227a47e3d7b Mon Sep 17 00:00:00 2001
From: Daniel Schierbeck <daniel.schierbeck@gmail.com>
Date: Mon, 8 Feb 2010 13:46:27 +0100
Subject: Remove commas

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index f0488ddc90..8ddf0cf3cf 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -319,7 +319,7 @@ $ rm public/index.html
 
 We need to do this as Rails will deliver any static file in the +public+ directory in preference to any dynamic contact we generate from the controllers.
 
-Now, you have to tell Rails where your actual home page is located. Open the file +config/routes.rb+ in your editor. This is your application's, _routing file_, which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. There are only comments in this file, so we need to add at the top the following:
+Now, you have to tell Rails where your actual home page is located. Open the file +config/routes.rb+ in your editor. This is your application's _routing file_ which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. There are only comments in this file, so we need to add at the top the following:
 
 <ruby>
 Blog::Application.routes.draw do |map|
-- 
cgit v1.2.3


From 79f02a473cb6aef00003745f23802314c8c89e7d Mon Sep 17 00:00:00 2001
From: Mikel Lindsaar <raasdnil@gmail.com>
Date: Tue, 9 Feb 2010 13:31:51 +1100
Subject: Altering the warnings

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 8ddf0cf3cf..ea8154cccc 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -9,7 +9,7 @@ This guide covers getting up and running with Ruby on Rails. After reading it, y
 
 endprologue.
 
-WARNING. This Guide is based on Rails 3.0. Some of the code shown here will not work in other versions of Rails.
+WARNING. This Guide is based on Rails 3.0. Some of the code shown here will not work in earlier versions of Rails.
 
 h3. Guide Assumptions
 
-- 
cgit v1.2.3


From 4bd37dadc45ac616117c9cf2b4fbb4c8f890226b Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Fri, 19 Feb 2010 20:27:24 +0100
Subject: getting started guide: script/generate -> rails generate

---
 railties/guides/source/getting_started.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 8ddf0cf3cf..ad328c6b51 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -431,7 +431,7 @@ Now you're ready to start working with posts. To do that, navigate to "http://lo
 
 !images/posts_index.png(Posts Index screenshot)!
 
-This is the result of Rails rendering the +index+ view of your posts. There aren't currently any posts in the database, but if you click the +New Post+ link you can create one. After that, you'll find that you can edit posts, look at their details, or destroy them. All of the logic and HTML to handle this was built by the single +script/generate scaffold+ command.
+This is the result of Rails rendering the +index+ view of your posts. There aren't currently any posts in the database, but if you click the +New Post+ link you can create one. After that, you'll find that you can edit posts, look at their details, or destroy them. All of the logic and HTML to handle this was built by the single +rails generate scaffold+ command.
 
 TIP: In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server.
 
-- 
cgit v1.2.3


From 02be581f45f74e735252afa167cee3ca6ab45b5e Mon Sep 17 00:00:00 2001
From: Xavier Noria <fxn@hashref.com>
Date: Fri, 19 Mar 2010 21:39:42 +0100
Subject: s/guides.rails.info/edgeguides.rubyonrails.org/ in a few places, and
 makes some links relative to work in either site

---
 railties/guides/source/getting_started.textile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'railties/guides/source/getting_started.textile')

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index a231713991..c479c2fb20 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -146,7 +146,7 @@ Usually run this as the root user:
 # gem install rails
 </shell>
 
-NOTE. In the Rails 3.0.0-beta, you will need to manually install the dependencies for Rails itself as a bug in rubygems will cause these to not be installed, see the "3.0 Release Notes":http://guides.rails.info/3_0_release_notes.html for the commands to run.
+NOTE. In the Rails 3.0.0-beta, you will need to manually install the dependencies for Rails itself as a bug in rubygems will cause these to not be installed, see the "3.0 Release Notes":3_0_release_notes.html for the commands to run.
 
 TIP. If you're working on Windows, you may find it easier to install "Instant Rails":http://instantrails.rubyforge.org/wiki/wiki.pl. Be aware, though, that Instant Rails releases tend to lag seriously behind the actual Rails version. Also, you will find that Rails development on Windows is overall less pleasant than on other operating systems. If at all possible, we suggest that you install a Linux virtual machine and use that for Rails development, instead of using Windows.
 
@@ -1417,7 +1417,7 @@ h3. What's Next?
 
 Now that you've seen your first Rails application, you should feel free to update it and experiment on your own. But you don't have to do everything without help. As you need assistance getting up and running with Rails, feel free to consult these support resources:
 
-* The "Ruby On Rails guides":http://guides.rails.info
+* The "Ruby On Rails guides":index.html
 * The "Ruby on Rails mailing list":http://groups.google.com/group/rubyonrails-talk
 * The "#rubyonrails":irc://irc.freenode.net/#rubyonrails channel on irc.freenode.net
 * The "Rails Wiki":http://wiki.rubyonrails.org/
-- 
cgit v1.2.3