Merge docrails

1 files changed, 20 insertions, 13 deletions

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index 054ca99985..756caea5fe 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -41,7 +41,7 @@ def new
 end
 </ruby>
 
-The "Layouts & rendering guide":layouts_and_rendering.html explains this in more detail.
+The "Layouts & Rendering Guide":layouts_and_rendering.html explains this in more detail.
 
 +ApplicationController+ inherits from +ActionController::Base+, which defines a number of helpful methods. This guide will cover some of these, but if you're curious to see what's in there, you can see all of them in the API documentation or in the source itself.
 
@@ -191,7 +191,7 @@ Session values are stored using key/value pairs like a hash:
 <ruby>
 class ApplicationController < ActionController::Base
 
-private
+  private
 
   # Finds the User with the ID stored in the session with the key
   # :current_user_id This is a common way to handle user login in
@@ -350,7 +350,8 @@ Before filters may halt the request cycle. A common before filter is one which r
 class ApplicationController < ActionController::Base
   before_filter :require_login
 
-private
+  private
+
   def require_login
     unless logged_in?
       flash[:error] = "You must be logged in to access this section"
@@ -374,7 +375,7 @@ The method simply stores an error message in the flash and redirects to the logi
 In this example the filter is added to +ApplicationController+ and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with +skip_before_filter+:
 
 <ruby>
-class LoginsController < Application
+class LoginsController < ApplicationController
   skip_before_filter :require_login, :only => [:new, :create]
 end
 </ruby>
@@ -390,10 +391,11 @@ Around filters are responsible for running the action, but they can choose not t
 <ruby>
 # Example taken from the Rails API filter documentation:
 # http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html
-class ApplicationController < Application
+class ApplicationController < ActionController::Base
   around_filter :catch_exceptions
 
-private
+  private
+
   def catch_exceptions
     yield
   rescue => exception
@@ -442,7 +444,7 @@ The Rails API documentation has "more information on using filters":http://api.r
 
 h3. Verification
 
-Verifications make sure certain criteria are met in order for a controller or action to run. They can specify that a certain key (or several keys in the form of an array) is present in the +params+, +session+ or +flash+ hashes or that a certain HTTP method was used or that the request was made using +XMLHTTPRequest+ (Ajax). The default action taken when these criteria are not met is to render a 400 Bad Request response, but you can customize this by specifying a redirect URL or rendering something else and you can also add flash messages and HTTP headers to the response. It is described in the "API documentation":http://api.rubyonrails.org/classes/ActionController/Verification/ClassMethods.html as "essentially a special kind of before_filter".
+Verifications make sure certain criteria are met in order for a controller or action to run. They can specify that a certain key (or several keys in the form of an array) is present in the +params+, +session+ or +flash+ hashes or that a certain HTTP method was used or that the request was made using +XMLHttpRequest+ (Ajax). The default action taken when these criteria are not met is to render a 400 Bad Request response, but you can customize this by specifying a redirect URL or rendering something else and you can also add flash messages and HTTP headers to the response. It is described in the "API documentation":http://api.rubyonrails.org/classes/ActionController/Verification/ClassMethods.html as "essentially a special kind of before_filter".
 
 Here's an example of using verification to make sure the user supplies a username and a password in order to log in:
 
@@ -575,7 +577,8 @@ class AdminController < ApplicationController
 
   before_filter :authenticate
 
-private
+  private
+
   def authenticate
     authenticate_or_request_with_http_basic do |username, password|
       username == USERNAME &&
@@ -597,7 +600,8 @@ class AdminController < ApplicationController
 
   before_filter :authenticate
 
-private
+  private
+
   def authenticate
     authenticate_or_request_with_http_digest do |username|
       USERS[username]
@@ -626,7 +630,7 @@ class ClientsController < ApplicationController
               :type => "application/pdf")
   end
 
-private
+  private
 
   def generate_pdf(client)
     Prawn::Document.new do
@@ -728,7 +732,8 @@ Here's how you can use +rescue_from+ to intercept all +ActiveRecord::RecordNotFo
 class ApplicationController < ActionController::Base
   rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found
 
-private
+  private
+
   def record_not_found
     render :text => "404 Not Found", :status => 404
   end
@@ -741,7 +746,8 @@ Of course, this example is anything but elaborate and doesn't improve on the def
 class ApplicationController < ActionController::Base
   rescue_from User::NotAuthorized, :with => :user_not_authorized
 
-private
+  private
+
   def user_not_authorized
     flash[:error] = "You don't have access to this section."
     redirect_to :back
@@ -757,7 +763,8 @@ class ClientsController < ApplicationController
     @client = Client.find(params[:id])
   end
 
-private
+  private
+
   # If the user is not authorized, just throw the exception.
   def check_authorization
     raise User::NotAuthorized unless current_user.admin?