Fix some formatting errors

for <code> elements
for (monospaced) displayed material
add some commas in enumerations.

1 files changed, 26 insertions, 24 deletions

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index 137349e2ff..f39d3088bd 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -63,12 +63,12 @@ ApplicationController inherits from ActionController::Base, which defines a numb
 
 h3. Parameters
 
-You will probably want to access data sent in by the user or other parameters in your controller actions. There are two kinds of parameters possible in a web application. The first are parameters that are sent as part of the URL, called query string parameters. The query string is everything after "?" in the URL. The second type of parameter is usually referred to as POST data. This information usually comes from a HTML form which has been filled in by the user. It's called POST data because it can only be sent as part of an HTTP POST request. Rails does not make any distinction between query string parameters and POST parameters, and both are available in the +params+ hash in your controller:
+You will probably want to access data sent in by the user or other parameters in your controller actions. There are two kinds of parameters possible in a web application. The first are parameters that are sent as part of the URL, called query string parameters. The query string is everything after "?" in the URL. The second type of parameter is usually referred to as POST data. This information usually comes from an HTML form which has been filled in by the user. It's called POST data because it can only be sent as part of an HTTP POST request. Rails does not make any distinction between query string parameters and POST parameters, and both are available in the +params+ hash in your controller:
 
 <ruby>
 class ClientsController < ActionController::Base
 
-  # This action uses query string parameters because it gets run by a HTTP
+  # This action uses query string parameters because it gets run by an HTTP
   # GET request, but this does not make any difference to the way in which
   # the parameters are accessed. The URL for this action would look like this
   # in order to list activated clients: /clients?status=activated
@@ -99,7 +99,7 @@ end
 
 h4. Hash and Array Parameters
 
-The params hash is not limited to one-dimensional keys and values. It can contain arrays and (nested) hashes. To send an array of values, append "[]" to the key name:
+The +params+ hash is not limited to one-dimensional keys and values. It can contain arrays and (nested) hashes. To send an array of values, append an empty pair of square brackets "[]" to the key name:
 
 <pre>
 GET /clients?ids[]=1&ids[]=2&ids[]=3
@@ -120,9 +120,9 @@ To send a hash you include the key name inside the brackets:
 </form>
 </html>
 
-The value of +params[:client]+ when this form is submitted  will be +{"name" => "Acme", "phone" => "12345", "address" => {"postcode" => "12345", "city" => "Carrot City"}}+. Note the nested hash in +params[:client][:address]+.
+When this form is submitted, the value of +params[:client]+ will be +{"name" => "Acme", "phone" => "12345", "address" => {"postcode" => "12345", "city" => "Carrot City"}}+. Note the nested hash in +params[:client][:address]+.
 
-Note that the params hash is actually an instance of HashWithIndifferentAccess from Active Support which is a subclass of Hash which lets you use symbols and strings interchangeably as keys.
+Note that the +params+ hash is actually an instance of HashWithIndifferentAccess from Active Support, which is a subclass of Hash that lets you use symbols and strings interchangeably as keys.
 
 h4. Routing Parameters
 
@@ -134,7 +134,7 @@ map.connect "/clients/:status", :controller => "clients", :action => "index", :f
 # ...
 </ruby>
 
-In this case, when a user opens the URL +/clients/active+, +params[:status]+ will be set to "active". When this route is used, +params[:foo]+ will also be set to "bar" just like it was passed in the query string in the same way +params[:action]+ will contain "index".
+In this case, when a user opens the URL +/clients/active+, +params[:status]+ will be set to "active". When this route is used, +params[:foo]+ will also be set to "bar" just like it was passed in the query string. In the same way +params[:action]+ will contain "index".
 
 h4. default_url_options
 
@@ -143,7 +143,7 @@ You can set global default parameters that will be used when generating URLs wit
 <ruby>
 class ApplicationController < ActionController::Base
 
-  #The options parameter is the hash passed in to +url_for+
+  # The options parameter is the hash passed in to 'url_for'
   def default_url_options(options)
     {:locale => I18n.locale}
   end
@@ -151,7 +151,7 @@ class ApplicationController < ActionController::Base
 end
 </ruby>
 
-These options will be used as a starting-point when generating, so it's possible they'll be overridden by +url_for+. Because this method is defined in the controller, you can define it on ApplicationController so it would be used for all URL generation, or you could define it on only one controller for all URLs generated there.
+These options will be used as a starting-point when generating URLs, so it's possible they'll be overridden by +url_for+. Because this method is defined in the controller, you can define it on ApplicationController so it would be used for all URL generation, or you could define it on only one controller for all URLs generated there.
 
 
 h3. Session
@@ -292,11 +292,13 @@ If you want a flash value to be carried over to another request, use the +keep+
 <ruby>
 class MainController < ApplicationController
 
-  # Let's say this action corresponds to root_url, but you want all requests here to be redirected to
-  # UsersController#index. If an action sets the flash and redirects here, the values would normally be
-  # lost when another redirect happens, but you can use keep to make it persist for another request.
+  # Let's say this action corresponds to root_url, but you want all requests
+  # here to be redirected to UsersController#index. If an action sets the flash
+  # and redirects here, the values would normally be lost when another redirect
+  # happens, but you can use 'keep' to make it persist for another request.
   def index
-    flash.keep # Will persist all flash values. You can also use a key to keep only that value: flash.keep(:notice)
+    flash.keep # Will persist all flash values. You can also use a key to keep
+      # only that kind of value: flash.keep(:notice)
     redirect_to users_url
   end
 
@@ -331,7 +333,7 @@ Your application can store small amounts of data on the client - called cookies
 class CommentsController < ApplicationController
 
   def new
-    #Auto-fill the commenter's name if it has been stored in a cookie
+    # Auto-fill the commenter's name if it has been stored in a cookie
     @comment = Comment.new(:name => cookies[:commenter_name])
   end
 
@@ -446,7 +448,7 @@ end
 
 Note that the filter in this case uses +send+ because the +logged_in?+ method is private and the filter is not run in the scope of the controller. This is not the recommended way to implement this particular filter, but in more simple cases it might be useful.
 
-The second way is to use a class (actually, any object that responds to the right methods will do) to handle the filtering. This is useful in cases that are more complex than can not be implemented in a readable and reusable way using the two other methods. As an example, you could rewrite the login filter again to use a class:
+The second way is to use a class (actually, any object that responds to the right methods will do) to handle the filtering. This is useful in cases that are more complex and can not be implemented in a readable and reusable way using the two other methods. As an example, you could rewrite the login filter again to use a class:
 
 <ruby>
 class ApplicationController < ActionController::Base
@@ -546,7 +548,7 @@ The "Security Guide":security.html has more about this and a lot of other securi
 
 h3. The request and response Objects
 
-In every controller there are two accessor methods pointing to the request and the response objects associated with the request cycle that is currently in execution. The +request+ method contains an instance of AbstractRequest and the +response+ method returns a +response+ object representing what is going to be sent back to the client.
+In every controller there are two accessor methods pointing to the request and the response objects associated with the request cycle that is currently in execution. The +request+ method contains an instance of AbstractRequest and the +response+ method returns a response object representing what is going to be sent back to the client.
 
 h4. The request Object
 
@@ -564,7 +566,7 @@ The request object contains a lot of useful information about the request coming
 * remote_ip - The IP address of the client.
 * url - The entire URL used for the request.
 
-h5. path_parameters, query_parameters and request_parameters
+h5. path_parameters, query_parameters, and request_parameters
 
 Rails collects all of the parameters sent along with the request in the +params+ hash, whether they are sent as part of the query string or the post body. The request object has three accessors that give you access to these parameters depending on where they came from. The +query_parameters+ hash contains parameters that were sent as part of the query string while the +request_parameters+ hash contains parameters sent as part of the post body. The +path_parameters+ hash contains parameters that were recognized by the routing as being part of the path leading to this particular controller and action.
 
@@ -589,14 +591,14 @@ response.headers["Content-Type"] = "application/pdf"
 
 h3. HTTP Authentications
 
-Rails comes with two built-in HTTP authentication mechanisms :
+Rails comes with two built-in HTTP authentication mechanisms:
 
 * Basic Authentication
 * Digest Authentication
 
 h4. HTTP Basic Authentication
 
-HTTP Basic authentication is an authentication scheme that is supported by the majority of browsers and other HTTP clients. As an example, consider an administration section which will only be available by entering a username and a password into the browser's HTTP Basic dialog window. Using the built-in authentication is quite easy and only requires you to use one method, +authenticate_or_request_with_http_basic+.
+HTTP basic authentication is an authentication scheme that is supported by the majority of browsers and other HTTP clients. As an example, consider an administration section which will only be available by entering a username and a password into the browser's HTTP basic dialog window. Using the built-in authentication is quite easy and only requires you to use one method, +authenticate_or_request_with_http_basic+.
 
 <ruby>
 class AdminController < ApplicationController
@@ -616,11 +618,11 @@ class AdminController < ApplicationController
 end
 </ruby>
 
-With this in place, you can create namespaced controllers that inherit from AdminController. The before filter will thus be run for all actions in those controllers, protecting them with HTTP Basic authentication.
+With this in place, you can create namespaced controllers that inherit from AdminController. The before filter will thus be run for all actions in those controllers, protecting them with HTTP basic authentication.
 
 h4. HTTP Digest Authentication
 
-HTTP Digest authentication is superior to the Basic authentication as it does not require the client to send unencrypted password over the network. Using Digest authentication with Rails is quite easy and only requires using one method, +authenticate_or_request_with_http_digest+.
+HTTP digest authentication is superior to the basic authentication as it does not require the client to send unencrypted password over the network. Using digest authentication with Rails is quite easy and only requires using one method, +authenticate_or_request_with_http_digest+.
 
 <ruby>
 class AdminController < ApplicationController
@@ -640,11 +642,11 @@ class AdminController < ApplicationController
 end
 </ruby>
 
-As seen in the example above, +authenticate_or_request_with_http_digest+ block takes only one argument - the username. And the block returns the password. Returning +false+ or +nil+ from the +authenticate_or_request_with_http_digest+ will cause authentication failure.
+As seen in the example above, the +authenticate_or_request_with_http_digest+ block takes only one argument - the username. And the block returns the password. Returning +false+ or +nil+ from the +authenticate_or_request_with_http_digest+ will cause authentication failure.
 
 h3. Streaming and File Downloads
 
-Sometimes you may want to send a file to the user instead of rendering an HTML page. All controllers in Rails have the +send_data+ and the +send_file+ methods, that will both stream data to the client. +send_file+ is a convenience method which lets you provide the name of a file on the disk and it will stream the contents of that file for you.
+Sometimes you may want to send a file to the user instead of rendering an HTML page. All controllers in Rails have the +send_data+ and the +send_file+ methods, which will both stream data to the client. +send_file+ is a convenience method that lets you provide the name of a file on the disk and it will stream the contents of that file for you.
 
 To stream data to the client, use +send_data+:
 
@@ -732,7 +734,7 @@ GET /clients/1.pdf
 
 h3. Parameter Filtering
 
-Rails keeps a log file for each environment (development, test and production) in the +log+ folder. These are extremely useful when debugging what's actually going on in your application, but in a live application you may not want every bit of information to be stored in the log file. The +filter_parameter_logging+ method can be used to filter out sensitive information from the log. It works by replacing certain values in the +params+ hash with "[FILTERED]" as they are written to the log. As an example, let's see how to filter all parameters with keys that include "password":
+Rails keeps a log file for each environment (development, test, and production) in the +log+ folder. These are extremely useful when debugging what's actually going on in your application, but in a live application you may not want every bit of information to be stored in the log file. The +filter_parameter_logging+ method can be used to filter out sensitive information from the log. It works by replacing certain values in the +params+ hash with "[FILTERED]" as they are written to the log. As an example, let's see how to filter all parameters with keys that include "password":
 
 <ruby>
 class ApplicationController < ActionController::Base
@@ -742,7 +744,7 @@ class ApplicationController < ActionController::Base
 end
 </ruby>
 
-The method works recursively through all levels of the params hash and takes an optional second parameter which is used as the replacement string if present. It can also take a block which receives each key in turn and replaces those for which the block returns true.
+The method works recursively through all levels of the +params+ hash and takes an optional second parameter which is used as the replacement string if present. It can also take a block which receives each key in turn and replaces those for which the block returns true.
 
 h3. Rescue