Merge branch 'master' of github.com:lifo/docrails

5 files changed, 27 insertions, 40 deletions

diff --git a/guides/source/asset_pipeline.textile b/guides/source/asset_pipeline.textile
index 464788f30f..982c4aa096 100644
--- a/guides/source/asset_pipeline.textile
+++ b/guides/source/asset_pipeline.textile
@@ -409,9 +409,9 @@ cannot see application objects or methods. *Heroku requires this to be false.*
 WARNING: If you set +config.assets.initialize_on_precompile+ to false, be sure to
 test +rake assets:precompile+ locally before deploying. It may expose bugs where
 your assets reference application objects or methods, since those are still
-in scope in development mode regardless of the value of this flag. Changing this flag also effects
+in scope in development mode regardless of the value of this flag. Changing this flag also affects
 engines. Engines can define assets for precompilation as well. Since the complete environment is not loaded,
-engines (or other gems) will not be loaded which can cause missing assets.
+engines (or other gems) will not be loaded, which can cause missing assets.
 
 Capistrano (v2.8.0 and above) includes a recipe to handle this in deployment. Add the following line to +Capfile+:
 
diff --git a/guides/source/caching_with_rails.textile b/guides/source/caching_with_rails.textile
index 0e811a2527..12bc32f4e1 100644
--- a/guides/source/caching_with_rails.textile
+++ b/guides/source/caching_with_rails.textile
@@ -92,7 +92,7 @@ INFO: Page caching runs in an after filter. Thus, invalid requests won't generat
 
 h4. Action Caching
 
-One of the issues with Page Caching is that you cannot use it for pages that require to restrict access somehow. This is where Action Caching comes in. Action Caching works like Page Caching except for the fact that the incoming web request does go from the webserver to the Rails stack and Action Pack so that before filters can be run on it before the cache is served. This allows authentication and other restriction to be run while still serving the result of the output from a cached copy.
+Page Caching cannot be used for actions that have before filters - for example, pages that require authentication. This is where Action Caching comes in. Action Caching works like Page Caching except the incoming web request hits the Rails stack so that before filters can be run on it before the cache is served. This allows authentication and other restrictions to be run while still serving the result of the output from a cached copy.
 
 Clearing the cache works in a similar way to Page Caching, except you use +expire_action+ instead of +expire_page+.
 
diff --git a/guides/source/getting_started.textile b/guides/source/getting_started.textile
index d12606c5de..59b12b49e5 100644
--- a/guides/source/getting_started.textile
+++ b/guides/source/getting_started.textile
@@ -119,10 +119,10 @@ After you create the blog application, switch to its folder to continue work dir
 $ cd blog
 </shell>
 
-The +rails new blog+ command we ran above created a folder in your working directory called <tt>blog</tt>. The <tt>blog</tt> directory has a number of auto-generated folders that make up the structure of a Rails application. 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 of the files and folders that Rails created by default:
+The +rails new blog+ command we ran above created a folder in your working directory called <tt>blog</tt>. The <tt>blog</tt> directory has a number of auto-generated files and folders that make up the structure of a Rails application. 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 of the files and folders that Rails created by default:
 
 |_.File/Folder|_.Purpose|
-|app/|Contains the controllers, models, views and assets for your application. You'll focus on this folder for the remainder of this guide.|
+|app/|Contains the controllers, models, views, helpers, mailers and assets 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.  This is covered in more detail in "Configuring Rails Applications":configuring.html|
 |config.ru|Rack configuration for Rack based servers used to start the application.|
 |db/|Contains your current database schema, as well as the database migrations.|
@@ -284,13 +284,13 @@ Missing template posts/new, application/new with {:locale=>[:en], :formats=>[:ht
 
 That's quite a lot of text! Let's quickly go through and understand what each part of it does.
 
-The first part identifies what template is missing. In this case, it's the +posts/new+ template. Rails will first look for this template. If it can't find it, then it will attempt to load a template called +application/new+. It looks for one here because the +PostsController+ inherits from +ApplicationController+.
+The first part identifies what template is missing. In this case, it's the +posts/new+ template. Rails will first look for this template. If not found, then it will attempt to load a template called +application/new+. It looks for one here because the +PostsController+ inherits from +ApplicationController+.
 
-The next part of the message contains a hash. The +:locale+ key in this hash simply indicates what spoken language template should be retrieved. By default, this is the English -- or "en" -- template. The next key, +:formats+ shows what formats of template Rails is after. The default is +:html+, and so Rails is looking for an HTML template. The final key, +:handlers+, is telling us what _template handlers_ could be used to render our template. +:erb+ is most commonly used for HTML templates, +:builder+ is used for XML templates, and +:coffee+ uses CoffeeScript to build JavaScript templates.
+The next part of the message contains a hash. The +:locale+ key in this hash simply indicates what spoken language template should be retrieved. By default, this is the English -- or "en" -- template. The next key, +:formats+ specifies the format of template to be served in response . The default format is +:html+, and so Rails is looking for an HTML template. The final key, +:handlers+, is telling us what _template handlers_ could be used to render our template. +:erb+ is most commonly used for HTML templates, +:builder+ is used for XML templates, and +:coffee+ uses CoffeeScript to build JavaScript templates.
 
 The final part of this message tells us where Rails has looked for the templates. Templates within a basic Rails application like this are kept in a single location, but in more complex applications it could be many different paths.
 
-The simplest template that would work in this case would be one located at +app/views/posts/new.html.erb+. The extension of this file name is key: the first extension is the _format_ of the template, and the second extension is the _handler_ that will be used. Rails is attempting to find a template called +posts/new+ within +app/views+ for the application. The format for this template can only be +html+ and the handler must be one of +erb+, +builder+ or +coffee+. Because you want to create a new HTML form, you will be using the +ERB+ language. Therefore the file should be called +posts/new.html.erb+ and be located inside the +app/views+ directory of the application.
+The simplest template that would work in this case would be one located at +app/views/posts/new.html.erb+. The extension of this file name is key: the first extension is the _format_ of the template, and the second extension is the _handler_ that will be used. Rails is attempting to find a template called +posts/new+ within +app/views+ for the application. The format for this template can only be +html+ and the handler must be one of +erb+, +builder+ or +coffee+. Because you want to create a new HTML form, you will be using the +ERB+ language. Therefore the file should be called +posts/new.html.erb+ and needs to be located inside the +app/views+ directory of the application.
 
 Go ahead now and create a new file at +app/views/posts/new.html.erb+ and write this content in it:
 
diff --git a/guides/source/migrations.textile b/guides/source/migrations.textile
index cb7ee1e6a2..28426de6d7 100644
--- a/guides/source/migrations.textile
+++ b/guides/source/migrations.textile
@@ -728,7 +728,7 @@ class AddFlagToProduct < ActiveRecord::Migration
   def change
     add_column :products, :flag, :boolean
     Product.all.each do |product|
-      product.update_attributes!(:flag => 'false')
+      product.update_attributes!(:flag => false)
     end
   end
 end
@@ -804,7 +804,7 @@ class AddFlagToProduct < ActiveRecord::Migration
   end
 
   def change
-    add_column :products, :flag, :integer
+    add_column :products, :flag, :boolean
     Product.reset_column_information
     Product.all.each do |product|
       product.update_attributes!(:flag => false)
diff --git a/guides/source/rails_on_rack.textile b/guides/source/rails_on_rack.textile
index 73e0f242cc..ff862273fd 100644
--- a/guides/source/rails_on_rack.textile
+++ b/guides/source/rails_on_rack.textile
@@ -148,20 +148,33 @@ You can swap an existing middleware in the middleware stack using +config.middle
 <ruby>
 # config/application.rb
 
-# Replace ActionController::Failsafe with Lifo::Failsafe
-config.middleware.swap ActionController::Failsafe, Lifo::Failsafe
+# Replace ActionDispatch::ShowExceptions with Lifo::ShowExceptions
+config.middleware.swap ActionDispatch::ShowExceptions, Lifo::ShowExceptions
 </ruby>
 
 h5. Middleware Stack is an Array
 
 The middleware stack behaves just like a normal +Array+. You can use any +Array+ methods to insert, reorder, or remove items from the stack. Methods described in the section above are just convenience methods.
 
-For example, the following removes the middleware matching the supplied class name:
+Append following lines to your application configuration:
 
 <ruby>
-config.middleware.delete(middleware)
+# config/application.rb
+config.middleware.delete "Rack::Lock"
 </ruby>
 
+And now if you inspect the middleware stack, you'll find that +Rack::Lock+ will not be part of it.
+
+<shell>
+$ rake middleware
+(in /Users/lifo/Rails/blog)
+use ActionDispatch::Static
+use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x00000001c304c8>
+use Rack::Runtime
+...
+run Myapp::Application.routes
+</shell>
+
 h4. Internal Middleware Stack
 
 Much of Action Controller's functionality is implemented as Middlewares. The following list explains the purpose of each of them:
@@ -234,32 +247,6 @@ Much of Action Controller's functionality is implemented as Middlewares. The fol
 
 TIP: It's possible to use any of the above middlewares in your custom Rack stack.
 
-h4. Customizing Internal Middleware Stack
-
-It's possible to replace the entire middleware stack with a custom stack using <tt>ActionController::Dispatcher.middleware=</tt>.
-
-Put the following in an initializer:
-
-<ruby>
-# config/initializers/stack.rb
-ActionController::Dispatcher.middleware = ActionController::MiddlewareStack.new do |m|
-  m.use ActionController::Failsafe
-  m.use ActiveRecord::QueryCache
-  m.use Rack::Head
-end
-</ruby>
-
-And now inspecting the middleware stack:
-
-<shell>
-$ rake middleware
-(in /Users/lifo/Rails/blog)
-use ActionController::Failsafe
-use ActiveRecord::QueryCache
-use Rack::Head
-run ActionController::Dispatcher.new
-</shell>
-
 h4. Using Rack Builder
 
 The following shows how to replace use +Rack::Builder+ instead of the Rails supplied +MiddlewareStack+.