railties 3.1.0.rc4 → 3.1.0.rc5

data/guides/source/association_basics.textile

@@ -443,7 +443,7 @@ class CreateAssemblyPartJoinTable < ActiveRecord::Migration
 end
 </ruby>
 
-We pass +:id => false+ to +create_table+ because that table does not represent a model. That's required for the association to work properly. If you observe any strange behaviour in a +has_and_belongs_to_many+ association like mangled models IDs, or exceptions about conflicting IDs chances are you forgot that bit.
+We pass +:id => false+ to +create_table+ because that table does not represent a model. That's required for the association to work properly. If you observe any strange behavior in a +has_and_belongs_to_many+ association like mangled models IDs, or exceptions about conflicting IDs chances are you forgot that bit.
 
 h4. Controlling Association Scope
 
@@ -1120,11 +1120,9 @@ h6(#has_many-collection-find). <tt><em>collection</em>.find(...)</tt>
 The <tt><em>collection</em>.find</tt> method finds objects within the collection. It uses the same syntax and options as +ActiveRecord::Base.find+.
 
 <ruby>
-@open_orders = @customer.orders.all(:conditions => "open = 1")
+@open_orders = @customer.orders.where(:open => 1)
 </ruby>
 
-NOTE: Starting Rails 3, supplying options to +ActiveRecord::Base.find+ method is discouraged. Use <tt><em>collection</em>.where</tt> instead when you need to pass conditions.
-
 h6(#has_many-collection-where). <tt><em>collection</em>.where(...)</tt>
 
 The <tt><em>collection</em>.where</tt> method finds objects within the collection based on the conditions supplied but the objects are loaded lazily meaning that the database is queried only when the object(s) are accessed.

data/guides/source/caching_with_rails.textile

@@ -15,7 +15,7 @@ h3. Basic Caching
 
 This is an introduction to the three types of caching techniques that Rails provides by default without the use of any third party plugins.
 
-To start playing with testing you'll want to ensure that +config.action_controller.perform_caching+ is set to +true+ if you're running in development mode. This flag is normally set in the corresponding +config/environments/*.rb+ and caching is disabled by default for development and test, and enabled for production.
+To start playing with caching you'll want to ensure that +config.action_controller.perform_caching+ is set to +true+, if you're running in development mode. This flag is normally set in the corresponding +config/environments/*.rb+ and caching is disabled by default for development and test, and enabled for production.
 
 <ruby>
 config.action_controller.perform_caching = true
@@ -23,9 +23,9 @@ config.action_controller.perform_caching = true
 
 h4. Page Caching
 
-Page caching is a Rails mechanism which allows the request for a generated page to be fulfilled by the webserver (i.e. apache or nginx), without ever having to go through the Rails stack at all. Obviously, this is super-fast. Unfortunately, it can't be applied to every situation (such as pages that need authentication) and since the webserver is literally just serving a file from the filesystem, cache expiration is an issue that needs to be dealt with.
+Page caching is a Rails mechanism which allows the request for a generated page to be fulfilled by the webserver (i.e. Apache or nginx), without ever having to go through the Rails stack at all. Obviously, this is super-fast. Unfortunately, it can't be applied to every situation (such as pages that need authentication) and since the webserver is literally just serving a file from the filesystem, cache expiration is an issue that needs to be dealt with.
 
-So, how do you enable this super-fast cache behavior? Simple, let's say you have a controller called +ProductsController+ and an +index+ action that lists all the products
+To enable page caching, you need to use the +caches_page+ method.
 
 <ruby>
 class ProductsController < ActionController
@@ -35,11 +35,10 @@ class ProductsController < ActionController
   def index
     @products = Products.all
   end
-
 end
 </ruby>
 
-The first time anyone requests +/products+, Rails will generate a file called +products.html+ and the webserver will then look for that file before it passes the next request for +/products+ to your Rails application.
+Let's say you have a controller called +ProductsController+ and an +index+ action that lists all the products. The first time anyone requests +/products+, Rails will generate a file called +products.html+ and the webserver will then look for that file before it passes the next request for +/products+ to your Rails application.
 
 By default, the page cache directory is set to +Rails.public_path+ (which is usually set to the +public+ folder) and this can be configured by changing the configuration setting +config.action_controller.page_cache_directory+. Changing the default from +public+ helps avoid naming conflicts, since you may want to put other static html in +public+, but changing this will require web server reconfiguration to let the web server know where to serve the cached files from.
 
@@ -104,7 +103,7 @@ INFO: Action caching runs in an after filter. Thus, invalid requests won't gener
 
 h4. Fragment Caching
 
-Life would be perfect if we could get away with caching the entire contents of a page or action and serving it out to the world. Unfortunately, dynamic web applications usually build pages with a variety of components not all of which have the same caching characteristics. In order to address such a dynamically created page where different parts of the page need to be cached and expired differently Rails provides a mechanism called Fragment Caching.
+Life would be perfect if we could get away with caching the entire contents of a page or action and serving it out to the world. Unfortunately, dynamic web applications usually build pages with a variety of components not all of which have the same caching characteristics. In order to address such a dynamically created page where different parts of the page need to be cached and expired differently, Rails provides a mechanism called Fragment Caching.
 
 Fragment Caching allows a fragment of view logic to be wrapped in a cache block and served out of the cache store when the next request comes in.
 
@@ -382,6 +381,7 @@ class ProductsController < ApplicationController
     # anything. The default render checks for this using the parameters
     # used in the previous call to stale? and will automatically send a
     # :not_modified. So that's it, you're done.
+  end
 end
 </ruby>
 
@@ -415,3 +415,4 @@ h3. Changelog
 * December  27, 2008: Typo fixes
 * November  23, 2008: Incremental updates with various suggested changes and formatting cleanup
 * September 15, 2008: Initial version by Aditya Chadha
+

data/guides/source/command_line.textile

@@ -5,7 +5,7 @@ Rails comes with every command line tool you'll need to
 * Create a Rails application
 * Generate models, controllers, database migrations, and unit tests
 * Start a development server
-* Mess with objects through an interactive shell
+* Experiment with objects through an interactive shell
 * Profile and benchmark your new creation
 
 endprologue.
@@ -51,15 +51,13 @@ $ rails new commandsapp
 
 Rails will set you up with what seems like a huge amount of stuff for such a tiny command! You've got the entire Rails directory structure now with all the code you need to run our simple application right out of the box.
 
-INFO: This output will seem very familiar when we get to the +generate+ command. Creepy foreshadowing!
-
 h4. +rails server+
 
-The +rails server+ command launches a small web server named WEBrick which comes bundled with Ruby. You'll use this any time you want to view your work through a web browser.
+The +rails server+ command launches a small web server named WEBrick which comes bundled with Ruby. You'll use this any time you want to access your application through a web browser.
 
-INFO: WEBrick isn't your only option for serving Rails. We'll get to that in a later section.
+INFO: WEBrick isn't your only option for serving Rails. We'll get to that "later":#different-servers.
 
-Without any prodding of any kind, +rails server+ will run our new shiny Rails app:
+With no further work, +rails server+ will run our new shiny Rails app:
 
 <shell>
 $ cd commandsapp
@@ -77,13 +75,21 @@ With just three commands we whipped up a Rails server listening on port 3000. Go
 
 You can also use the alias "s" to start the server: <tt>rails s</tt>.
 
+The server can be run on a different port using the +-p+ option. The default development environment can be changed using +-e+.
+
+<shell>
+$ rails server -e production -p 4000
+</shell>
+
 h4. +rails generate+
 
-The +rails generate+ command uses templates to create a whole lot of things. You can always find out what's available by running +rails generate+ by itself. Let's do that:
+The +rails generate+ command uses templates to create a whole lot of things. Running +rails generate+ by itself gives a list of available generators:
+
+You can also use the alias "g" to invoke the generator command: <tt>rails g</tt>.
 
 <shell>
 $ rails generate
-Usage: rails generate generator [args] [options]
+Usage: rails generate GENERATOR [args] [options]
 
 ...
 ...
@@ -99,7 +105,7 @@ Rails:
 
 NOTE: You can install more generators through generator gems, portions of plugins you'll undoubtedly install, and you can even create your own!
 
-Using generators will save you a large amount of time by writing *boilerplate code*, code that is necessary for the app to work, but not necessary for you to spend time writing. That's what we have computers for.
+Using generators will save you a large amount of time by writing *boilerplate code*, code that is necessary for the app to work.
 
 Let's make our own controller with the controller generator. But what command should we use? Let's ask the generator:
 
@@ -148,7 +154,8 @@ $ rails generate controller Greetings hello
      create      test/unit/helpers/greetings_helper_test.rb
      invoke  assets
      create    app/assets/javascripts/greetings.js
-     create    app/assets/stylesheets/greetings.css
+     invoke    css
+     create      app/assets/stylesheets/greetings.css
 
 </shell>
 
@@ -171,7 +178,7 @@ Then the view, to display our message (in +app/views/greetings/hello.html.erb+):
 <p><%= @message %></p>
 </html>
 
-Deal. Go check it out in your browser. Fire up your server using +rails server+.
+Fire up your server using +rails server+.
 
 <shell>
 $ rails server
@@ -184,7 +191,7 @@ The URL will be "http://localhost:3000/greetings/hello":http://localhost:3000/gr
 
 INFO: With a normal, plain-old Rails application, your URLs will generally follow the pattern of http://(host)/(controller)/(action), and a URL like http://(host)/(controller) will hit the *index* action of that controller.
 
-Rails comes with a generator for data models too:
+Rails comes with a generator for data models too.
 
 <shell>
 $ rails generate model
@@ -288,11 +295,7 @@ You can also use the alias "db" to invoke the dbconsole: <tt>rails db</tt>.
 
 h4. +rails plugin+
 
-The +rails plugin+ command simplifies plugin management; think a miniature version of the Gem utility. Let's walk through installing a plugin. You can call the sub-command +discover+, which sifts through repositories looking for plugins, or call +source+ to add a specific repository of plugins, or you can specify the plugin location directly.
-
-Let's say you're creating a website for a client who wants a small accounting system. Every event having to do with money must be logged, and must never be deleted. Wouldn't it be great if we could override the behavior of a model to never actually take its record out of the database, but instead, just set a field?
-
-There is such a thing! The plugin we're installing is called +acts_as_paranoid+, and it lets models implement a +deleted_at+ column that gets set when you call destroy. Later, when calling find, the plugin will tack on a database check to filter out "deleted" things.
+The +rails plugin+ command simplifies plugin management. Plugins can be installed by name or their repository URLs. You need to have Git installed if you want to install a plugin from a Git repo. The same holds for Subversion too.
 
 <shell>
 $ rails plugin install https://github.com/technoweenie/acts_as_paranoid.git
@@ -310,6 +313,14 @@ h4. +rails runner+
 $ rails runner "Model.long_running_method"
 </shell>
 
+You can also use the alias "r" to invoke the runner: <tt>rails r</tt>.
+
+You can specify the environment in which the +runner+ command should operate using the +-e+ switch.
+
+<shell>
+$ rails runner -e staging "Model.long_running_method"
+</shell>
+
 h4. +rails destroy+
 
 Think of +destroy+ as the opposite of +generate+. It'll figure out what generate did, and undo it.
@@ -388,13 +399,56 @@ h4. +db+
 
 The most common tasks of the +db:+ Rake namespace are +migrate+ and +create+, and it will pay off to try out all of the migration rake tasks (+up+, +down+, +redo+, +reset+). +rake db:version+ is useful when troubleshooting, telling you the current version of the database.
 
+More information about migrations can be found in the "Migrations":migrations.html guide.
+
 h4. +doc+
 
-If you want to strip out or rebuild any of the Rails documentation (including this guide!), the +doc:+ namespace has the tools. Stripping documentation is mainly useful for slimming your codebase, like if you're writing a Rails application for an embedded platform.
+The +doc:+ namespace has the tools to generate documentation for your app, API documentation, guides. Documentation can also be stripped which is mainly useful for slimming your codebase, like if you're writing a Rails application for an embedded platform.
+
+* +rake doc:app+ generates documentation for your application in +doc/app+.
+* +rake doc:guides+ generates Rails guides in +doc/guides+.
+* +rake doc:rails+ generates API documentation for Rails in +doc/api+.
+* +rake doc:plugins+ generates API documentation for all the plugins installed in the application in +doc/plugins+.
+* +rake doc:clobber_plugins+ removes the generated documentation for all plugins.
 
 h4. +notes+
 
-These tasks will search through your code for commented lines beginning with "FIXME", "OPTIMIZE", "TODO", or any custom annotation (like XXX) and show you them.
++rake notes+ will search through your code for comments beginning with FIXME, OPTIMIZE or TODO. The search is only done in files with extension +.builder+, +.rb+, +.rxml+, +.rhtml+ and +.erb+ for both default and custom annotations.
+
+<shell>
+$ rake notes
+(in /home/foobar/commandsapp)
+app/controllers/admin/users_controller.rb:
+  * [ 20] [TODO] any other way to do this?
+  * [132] [FIXME] high priority for next deploy
+
+app/model/school.rb:
+  * [ 13] [OPTIMIZE] refactor this code to make it faster
+  * [ 17] [FIXME]
+</shell>
+
+If you are looking for a specific annotation, say FIXME, you can use +rake notes:fixme+. Note that you have to lower case the annotation's name.
+
+<shell>
+$ rake notes:fixme
+(in /home/foobar/commandsapp)
+app/controllers/admin/users_controller.rb:
+  * [132] high priority for next deploy
+
+app/model/school.rb:
+  * [ 17]
+</shell>
+
+You can also use custom annotations in your code and list them using +rake notes:custom+ by specifying the annotation using an environment variable +ANNOTATION+.
+
+<shell>
+$ rake notes:custom ANNOTATION=BUG
+(in /home/foobar/commandsapp)
+app/model/post.rb:
+  * [ 23] Have to fix this one before pushing!
+</shell>
+
+NOTE. When using specific annotations and custom annotations, the annotation name (FIXME, BUG etc) is not displayed in the output lines.
 
 h4. +routes+
 
@@ -478,11 +532,13 @@ development:
 ...
 </shell>
 
-It also generated some lines in our database.yml configuration corresponding to our choice of PostgreSQL for database. The only catch with using the SCM options is that you have to make your application's directory first, then initialize your SCM, then you can run the +rails new+ command to generate the basis of your app.
+It also generated some lines in our database.yml configuration corresponding to our choice of PostgreSQL for database.
+
+NOTE. The only catch with using the SCM options is that you have to make your application's directory first, then initialize your SCM, then you can run the +rails new+ command to generate the basis of your app.
 
-h4. +server+ with Different Backends
+h4(#different-servers). +server+ with Different Backends
 
-Many people have created a large number different web servers in Ruby, and many of them can be used to run Rails. Since version 2.3, Rails uses Rack to serve its webpages, which means that any webserver that implements a Rack handler can be used. This includes WEBrick, Mongrel, Thin, and Phusion Passenger (to name a few!).
+Many people have created a large number of different web servers in Ruby, and many of them can be used to run Rails. Since version 2.3, Rails uses Rack to serve its webpages, which means that any webserver that implements a Rack handler can be used. This includes WEBrick, Mongrel, Thin, and Phusion Passenger (to name a few!).
 
 NOTE: For more details on the Rack integration, see "Rails on Rack":rails_on_rack.html.
 
@@ -504,97 +560,3 @@ $ rails server mongrel
 => Rails 3.1.0 application starting on http://0.0.0.0:3000
 ...
 </shell>
-
-h4. The Rails Generation: Generators
-
-INFO: For a good rundown on generators, see "Understanding Generators":http://wiki.rubyonrails.org/rails/pages/UnderstandingGenerators. A lot of its material is presented here.
-
-Generators are code that generates code. Let's experiment by building one. Our generator will generate a text file.
-
-The Rails generator by default looks in these places for available generators, where Rails.root is the root of your Rails application, like /home/foobar/commandsapp:
-
-* Rails.root/lib/generators
-* Rails.root/vendor/generators
-* Inside any plugin with a directory like "generators" or "rails_generators"
-* ~/.rails/generators
-* Inside any Gem you have installed with a name ending in "_generator"
-* Inside any Gem installed with a "rails_generators" path, and a file ending in "_generator.rb"
-* Finally, the builtin Rails generators (controller, model, mailer, etc.)
-
-Let's try the fourth option (in our home directory), which will be easy to clean up later:
-
-<shell>
-$ mkdir -p ~/.rails/generators/tutorial_test/templates
-$ touch ~/.rails/generators/tutorial_test/templates/tutorial.erb
-$ touch ~/.rails/generators/tutorial_test/tutorial_test_generator.rb
-</shell>
-
-We'll fill +tutorial_test_generator.rb+ out with:
-
-<ruby>
-class TutorialTestGenerator < Rails::Generator::Base
-  def initialize(*runtime_args)
-    super(*runtime_args)
-    @tut_args = runtime_args
-  end
-
-  def manifest
-    record do |m|
-      m.directory "public"
-      m.template "tutorial.erb", File.join("public", "tutorial.txt"),
-        :assigns => { :args => @tut_args }
-    end
-  end
-end
-</ruby>
-
-We take whatever args are supplied, save them to an instance variable, and literally copying from the Rails source, implement a +manifest+ method, which calls +record+ with a block, and we:
-
-* Check there's a *public* directory. You bet there is.
-* Run the ERB template called "tutorial.erb".
-* Save it into "Rails.root/public/tutorial.txt".
-* Pass in the arguments we saved through the +:assigns+ parameter.
-
-Next we'll build the template:
-
-<shell>
-$ cat ~/.rails/generators/tutorial_test/templates/tutorial.erb
-I'm a template!
-
-I got assigned some args:
-<%= require 'pp'; PP.pp(args, "") %>
-</shell>
-
-Then we'll make sure it got included in the list of available generators:
-
-<shell>
-$ rails generate
-...
-...
-Installed Generators
-  User: tutorial_test
-</shell>
-
-SWEET! Now let's generate some text, yeah!
-
-<shell>
-$ rails generate tutorial_test arg1 arg2 arg3
-      exists  public
-      create  public/tutorial.txt
-</shell>
-
-And the result:
-
-<shell>
-$ cat public/tutorial.txt
-I'm a template!
-
-I got assigned some args:
-[["arg1", "arg2", "arg3"],
- {:collision=>:ask,
-  :quiet=>false,
-  :generator=>"tutorial_test",
-  :command=>:create}]
-</shell>
-
-Tada!

data/guides/source/configuring.textile

@@ -98,7 +98,7 @@ NOTE. The +config.asset_path+ configuration is ignored if the asset pipeline is
 
 * +config.secret_token+ used for specifying a key which allows sessions for the application to be verified against a known secure key to prevent tampering. Applications get +config.secret_token+ initialized to a random key in +config/initializers/secret_token.rb+.
 
-* +config.serve_static_assets+ configures Rails to serve static assets. Defaults to true, but in the production environment is turned off. The server software used to run the application should be used to serve the assets instead.
+* +config.serve_static_assets+ configures Rails itself to serve static assets. Defaults to true, but in the production environment is turned off as the server software (e.g. Nginx or Apache) used to run the application should serve static assets instead. Unlike the default setting set this to true when running (absolutely not recommended!) or testing your app in production mode using WEBrick. Otherwise you won´t be able use page caching and requests for files that exist regularly under the public directory will anyway hit your Rails app.
 
 * +config.session_store+ is usually set up in +config/initializers/session_store.rb+ and specifies what class to use to store the session. Possible values are +:cookie_store+ which is the default, +:mem_cache_store+, and +:disabled+. The last one tells Rails not to deal with sessions. Custom session stores can also be specified:
 
@@ -116,8 +116,25 @@ WARNING: Threadsafe operation is incompatible with the normal workings of develo
 
 * +config.whiny_nils+ enables or disables warnings when a certain set of methods are invoked on +nil+ and it does not respond to them. Defaults to true in development and test environments.
 
+h4. Configuring Assets
+
+Rails 3.1, by default, is set up to use the +sprockets+ gem to manage assets within an application. This gem concatenates and compresses assets in order to make serving them much less painful.
+
 * +config.assets.enabled+ a flag that controls whether the asset pipeline is enabled. It is explicitly initialized in +config/application.rb+.
 
+* +config.assets.compress+ a flag that enables the compression of compiled assets. It is explicitly set to true in +config/production.rb+.
+
+* +config.assets.css_compressor+ defines the CSS compressor to use. Only supported value at the moment is +:yui+, which uses the +yui-compressor+ gem.
+
+* +config.assets.js_compressor+ defines the JavaScript compressor to use. Possible values are +:closure+, +:uglifier+ and +:yui+ which require the use of the +closure-compiler+, +uglifier+ or +yui-compressor+ gems respectively.
+
+* +config.assets.paths+ contains the paths which are used to look for assets. Appending paths to this configuration option will cause those paths to be used in the search for assets.
+
+* +config.assets.precompile+ allows you to specify additional assets (other than +application.css+ and +application.js+) which are to be precompiled when +rake assets:precompile+ is run.
+
+* +config.assets.prefix+ defines the prefix where assets are served from. Defaults to +/assets+.
+
+
 h4. Configuring Generators
 
 Rails 3 allows you to alter what generators are used with the +config.generators+ method. This method takes a block:
@@ -220,21 +237,21 @@ h4. Configuring Active Record
 
 * +config.active_record.table_name_suffix+ lets you set a global string to be appended to table names. If you set this to +_northwest+, then the Customer class will look for +customers_northwest+ as its table. The default is an empty string.
 
-* +config.active_record.pluralize_table_names+ specifies whether Rails will look for singular or plural table names in the database. If set to +true+ (the default), then the Customer class will use the +customers+ table. If set to +false+, then the Customer class will use the +customer+ table.
+* +config.active_record.pluralize_table_names+ specifies whether Rails will look for singular or plural table names in the database. If set to true (the default), then the Customer class will use the +customers+ table. If set to false, then the Customer class will use the +customer+ table.
 
 * +config.active_record.default_timezone+ determines whether to use +Time.local+ (if set to +:local+) or +Time.utc+ (if set to +:utc+) when pulling dates and times from the database. The default is +:utc+ for Rails, although Active Record defaults to +:local+ when used outside of Rails.
 
 * +config.active_record.schema_format+ controls the format for dumping the database schema to a file. The options are +:ruby+ (the default) for a database-independent version that depends on migrations, or +:sql+ for a set of (potentially database-dependent) SQL statements.
 
-* +config.active_record.timestamped_migrations+ controls whether migrations are numbered with serial integers or with timestamps. The default is +true+, to use timestamps, which are preferred if there are multiple developers working on the same application.
+* +config.active_record.timestamped_migrations+ controls whether migrations are numbered with serial integers or with timestamps. The default is true, to use timestamps, which are preferred if there are multiple developers working on the same application.
 
-* +config.active_record.lock_optimistically+ controls whether Active Record will use optimistic locking. By default this is +true+.
+* +config.active_record.lock_optimistically+ controls whether Active Record will use optimistic locking and is true by default.
 
 * +config.active_record.whitelist_attributes+ will create an empty whitelist of attributes available for mass-assignment security for all models in your app.
 
 The MySQL adapter adds one additional configuration option:
 
-* +ActiveRecord::ConnectionAdapters::MysqlAdapter.emulate_booleans+ controls whether Active Record will consider all +tinyint(1)+ columns in a MySQL database to be booleans. By default this is +true+.
+* +ActiveRecord::ConnectionAdapters::MysqlAdapter.emulate_booleans+ controls whether Active Record will consider all +tinyint(1)+ columns in a MySQL database to be booleans and is true by default.
 
 The schema dumper adds one additional configuration option:
 
@@ -260,7 +277,7 @@ h4. Configuring Action Controller
 
 * +config.action_controller.request_forgery_protection_token+ sets the token parameter name for RequestForgery. Calling +protect_from_forgery+ sets it to +:authenticity_token+ by default.
 
-* +config.action_controller.allow_forgery_protection+ enables or disables CSRF protection. By default this is +false+ in test mode and +true+ in all other modes.
+* +config.action_controller.allow_forgery_protection+ enables or disables CSRF protection. By default this is false in test mode and true in all other modes.
 
 * +config.action_controller.relative_url_root+ can be used to tell Rails that you are deploying to a subdirectory. The default is +ENV['RAILS_RELATIVE_URL_ROOT']+.
 
@@ -330,7 +347,7 @@ And can reference in the view with the following code:
 <%= stylesheet_link_tag :special %>
 </ruby>
 
-* +ActionView::Helpers::AssetTagHelper::AssetPaths.cache_asset_ids+ With the cache enabled, the asset tag helper methods will make fewer expensive file system calls (the default implementation checks the file system timestamp). However this prevents you from modifying any asset files while the server is running.
+* +config.action_view.cache_asset_ids+ With the cache enabled, the asset tag helper methods will make fewer expensive file system calls (the default implementation checks the file system timestamp). However this prevents you from modifying any asset files while the server is running.
 
 h4. Configuring Action Mailer
 
@@ -350,11 +367,11 @@ There are a number of settings available on +config.action_mailer+:
 ** +:location+ - The location of the sendmail executable. Defaults to +/usr/sbin/sendmail+.
 ** +:arguments+ - The command line arguments. Defaults to +-i -t+.
 
-* +config.action_mailer.raise_delivery_errors+ specifies whether to raise an error if email delivery cannot be completed. It defaults to +true+.
+* +config.action_mailer.raise_delivery_errors+ specifies whether to raise an error if email delivery cannot be completed. It defaults to true.
 
 * +config.action_mailer.delivery_method+ defines the delivery method. The allowed values are +:smtp+ (default), +:sendmail+, and +:test+.
 
-* +config.action_mailer.perform_deliveries+ specifies whether mail will actually be delivered. By default this is +true+; it can be convenient to set it to +false+ for testing.
+* +config.action_mailer.perform_deliveries+ specifies whether mail will actually be delivered and is true by default. It can be convenient to set it to false for testing.
 
 * +config.action_mailer.default+ configures Action Mailer defaults. These default to:
 <ruby>
@@ -366,12 +383,12 @@ There are a number of settings available on +config.action_mailer+:
 
 * +config.action_mailer.observers+ registers observers which will be notified when mail is delivered.
 <ruby>
-config.active_record.observers = ["MailObserver"]
+config.action_mailer.observers = ["MailObserver"]
 </ruby>
 
 * +config.action_mailer.interceptors+ registers interceptors which will be called before mail is sent.
 <ruby>
-config.active_record.interceptors = ["MailInterceptor"]
+config.action_mailer.interceptors = ["MailInterceptor"]
 </ruby>
 
 h4. Configuring Active Resource
@@ -478,13 +495,13 @@ Serves as a placeholder so that +:load_environment_config+ can be defined to run
 
 *+set_clear_dependencies_hook+* Provides a hook for +active_record.set_dispatch_hooks+ to use, which will run before this initializer. This initializer -- which runs only if +cache_classes+ is set to +false+ -- uses +ActionDispatch::Callbacks.after+ to remove the constants which have been referenced during the request from the object space so that they will be reloaded during the following request.
 
-*+initialize_dependency_mechanism+* If +config.cache_classes+ is set to +true+, configures +ActiveSupport::Dependencies.mechanism+ to +require+ dependencies rather than +load+ them.
+*+initialize_dependency_mechanism+* If +config.cache_classes+ is true, configures +ActiveSupport::Dependencies.mechanism+ to +require+ dependencies rather than +load+ them.
 
 *+bootstrap_hook+* Runs all configured +before_initialize+ blocks.
 
 *+i18n.callbacks+* In the development environment, sets up a +to_prepare+ callback which will call +I18n.reload!+ if any of the locales have changed since the last request. In production mode this callback will only run on the first request.
 
-*+active_support.initialize_whiny_nils+* Requires +active_support/whiny_nil+ if +config.whiny_nils+ is set to +true+. This file will output errors such as:
+*+active_support.initialize_whiny_nils+* Requires +active_support/whiny_nil+ if +config.whiny_nils+ is true. This file will output errors such as:
 
 <plain>
   Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id
@@ -506,7 +523,7 @@ The error occurred while evaluating nil.each
 
 *+action_view.cache_asset_ids+* Sets +ActionView::Helpers::AssetTagHelper::AssetPaths.cache_asset_ids+ to +false+ when Active Support loads, but only if +config.cache_classes+ is too.
 
-*+action_view.javascript_expansions+* Registers the expansions set up by +config.action_view.javascript_expansions+ and +config.action_view.stylesheet_expansions+ to be recognised by Action View and therefore usable in the views.
+*+action_view.javascript_expansions+* Registers the expansions set up by +config.action_view.javascript_expansions+ and +config.action_view.stylesheet_expansions+ to be recognized by Action View and therefore usable in the views.
 
 *+action_view.set_configs+* Sets up Action View by using the settings in +config.action_view+ by +send+'ing the method names as setters to +ActionView::Base+ and passing the values through.
 
@@ -568,13 +585,13 @@ The error occurred while evaluating nil.each
 
 *+build_middleware_stack+* Builds the middleware stack for the application, returning an object which has a +call+ method which takes a Rack environment object for the request.
 
-*+eager_load!+* If +config.cache_classes+ is +true+, runs the +config.before_eager_load+ hooks and then calls +eager_load!+ which will load all the Ruby files from +config.eager_load_paths+.
+*+eager_load!+* If +config.cache_classes+ is true, runs the +config.before_eager_load+ hooks and then calls +eager_load!+ which will load all the Ruby files from +config.eager_load_paths+.
 
 *+finisher_hook+* Provides a hook for after the initialization of process of the application is complete, as well as running all the +config.after_initialize+ blocks for the application, railties and engines.
 
 *+set_routes_reloader+* Configures Action Dispatch to reload the routes file using +ActionDispatch::Callbacks.to_prepare+.
 
-*+disable_dependency_loading+* Disables the automatic dependency loading if the +config.cache_classes+ is set to +true+ and +config.dependency_loading+ is set to +false+.
+*+disable_dependency_loading+* Disables the automatic dependency loading if the +config.cache_classes+ is set to true and +config.dependency_loading+ is set to false.
 
 h3. Changelog
 
@@ -582,4 +599,4 @@ h3. Changelog
 * November 26, 2010: Removed all config settings not available in Rails 3 ("Ryan Bigg":http://ryanbigg.com)
 * August 13, 2009: Updated with config syntax and added general configuration options by "John Pignata"
 * January 3, 2009: First reasonably complete draft by "Mike Gunderloy":credits.html#mgunderloy
-* November 5, 2008: Rough outline by "Mike Gunderloy":credits.html#mgunderloy
+* November 5, 2008: Rough outline by "Mike Gunderloy":credits.html#mgunderloy