Change code -> source in code blocks

6 files changed, 14 insertions, 14 deletions

diff --git a/railties/doc/guides/actioncontroller/cookies.txt b/railties/doc/guides/actioncontroller/cookies.txt
index dbcec23e45..a845e452b2 100644
--- a/railties/doc/guides/actioncontroller/cookies.txt
+++ b/railties/doc/guides/actioncontroller/cookies.txt
@@ -4,7 +4,7 @@ Your application can store small amounts of data on the client - called cookies
 
 TODO: Find a real-world example where cookies are used
 
-[code, ruby]
+[source, ruby]
 -----------------------------------------
 class FooController < ApplicationController
 
diff --git a/railties/doc/guides/actioncontroller/filters.txt b/railties/doc/guides/actioncontroller/filters.txt
index 96078ea208..2baf92d6ef 100644
--- a/railties/doc/guides/actioncontroller/filters.txt
+++ b/railties/doc/guides/actioncontroller/filters.txt
@@ -2,7 +2,7 @@
 
 Filters are methods that are run before, after or "around" a controller action. For example, one filter might check to see if the logged in user has the right credentials to access that particular controller or action. Filters are inherited, so if you set a filter on ApplicationController, it will be run on every controller in your application. A common, simple filter is one which requires that a user is logged in for an action to be run. Let's define the filter method first:
 
-[code, ruby]
+[source, ruby]
 ---------------------------------
 class ApplicationController < ActionController::Base
 
@@ -29,7 +29,7 @@ end
 
 The method simply stores an error message in the flash and redirects to the login form if the user is not logged in. If a before filter (a filter which is run before the action) renders or redirects, the action will not run. If there are additional filters scheduled to run after the rendering/redirecting filter, they are also cancelled. To use this filter in a controller, use the "before_filter":http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html#M000704 method:
 
-[code, ruby]
+[source, ruby]
 ---------------------------------
 class ApplicationController < ActionController::Base
 
@@ -40,7 +40,7 @@ end
 
 In this example, the filter is added to ApplicationController and thus all controllers in the application. 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, so to prevent this filter from running you can use "skip_before_filter":http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html#M000711 :
 
-[code, ruby]
+[source, ruby]
 ---------------------------------
 class LoginsController < Application
 
@@ -57,7 +57,7 @@ In addition to the before filters, you can run filters after an action has run o
 
 TODO: Find a real example for an around filter
 
-[code, ruby]
+[source, ruby]
 ---------------------------------
 class ApplicationController < Application
 
@@ -80,7 +80,7 @@ While the most common way to use filters is by creating private methods and usin
 
 The first is to use a block directly with the *_filter methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritte to use a block:
 
-[code, ruby]
+[source, ruby]
 ---------------------------------
 class ApplicationController < ActionController::Base
 
@@ -93,7 +93,7 @@ Note that the filter in this case uses `send` because the `logged_in?` method is
 
 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, we will rewrite the login filter again to use a class:
 
-[code, ruby]
+[source, ruby]
 ---------------------------------
 class ApplicationController < ActionController::Base
 
diff --git a/railties/doc/guides/actioncontroller/http_auth.txt b/railties/doc/guides/actioncontroller/http_auth.txt
index e3361609a9..5a95de0bb3 100644
--- a/railties/doc/guides/actioncontroller/http_auth.txt
+++ b/railties/doc/guides/actioncontroller/http_auth.txt
@@ -2,7 +2,7 @@
 
 Rails comes with built-in HTTP Basic authentication. This is an authentication scheme that is supported by the majority of browsers and other HTTP clients. As an example, we will create 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://api.rubyonrails.org/classes/ActionController/HttpAuthentication/Basic/ControllerMethods.html#M000610
 
-[code, ruby]
+[source, ruby]
 -------------------------------------
 class AdminController < ApplicationController
 
diff --git a/railties/doc/guides/actioncontroller/parameter_filtering.txt b/railties/doc/guides/actioncontroller/parameter_filtering.txt
index e71afac662..dce4b252c3 100644
--- a/railties/doc/guides/actioncontroller/parameter_filtering.txt
+++ b/railties/doc/guides/actioncontroller/parameter_filtering.txt
@@ -2,7 +2,7 @@
 
 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":http://api.rubyonrails.org/classes/ActionController/Base.html#M000837 can be used to filter out sensitive information from the log. It works by replacing certain keys in the `params` hash with "[FILTERED]" before they are written to the log. As an example, let's see how to filter all parameters with keys that include "password":
 
-[code, ruby]
+[source, ruby]
 -------------------------
 class ApplicationController < ActionController::Base
 
diff --git a/railties/doc/guides/actioncontroller/params.txt b/railties/doc/guides/actioncontroller/params.txt
index c7a61d3cc0..67f97b6135 100644
--- a/railties/doc/guides/actioncontroller/params.txt
+++ b/railties/doc/guides/actioncontroller/params.txt
@@ -2,7 +2,7 @@
 
 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, 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:
 
-[code, ruby]
+[source, ruby]
 -------------------------------------
 class ClientsController < ActionController::Base
 
diff --git a/railties/doc/guides/actioncontroller/streaming.txt b/railties/doc/guides/actioncontroller/streaming.txt
index b125f4b6c5..6026a8c51b 100644
--- a/railties/doc/guides/actioncontroller/streaming.txt
+++ b/railties/doc/guides/actioncontroller/streaming.txt
@@ -4,7 +4,7 @@ Sometimes you may want to send a file to the user instead of rendering an HTML p
 
 To stream data to the client, use `send_data`:
 
-[code, ruby]
+[source, ruby]
 ----------------------------
 require "prawn"
 class ClientsController < ApplicationController
@@ -35,7 +35,7 @@ The `download_pdf` action in the example above will call a private method which
 
 If you want to send a file that already exists on disk, use the `send_file` method. This is usually not recommended, but can be useful if you want to perform some authentication before letting the user download the file.
 
-[code, ruby]
+[source, ruby]
 ----------------------------
 class ClientsController < ApplicationController
 
@@ -58,7 +58,7 @@ This will read and stream the file 4Kb at the time, avoiding loading the entire
 
 While `send_data` works just fine, if you are creating a RESTful application having separate actions for file downloads is a bit ugly. In REST terminology, the PDF file from the example above can be considered just another representation of the client resource. Rails provides an easy and quite sleek way of doing "RESTful downloads". Let's try to rewrite the example so that the PDF download is a part of the `show` action:
 
-[code, ruby]
+[source, ruby]
 ----------------------------
 class ClientsController < ApplicationController
 
@@ -77,7 +77,7 @@ end
 
 In order for this example to work, we have to add the PDF MIME type to Rails. This can be done by adding the following line to the file `config/initializers/mime_types.rb`:
 
-[code, ruby]
+[source, ruby]
 ----------------------------
 Mime::Type.register "application/pdf", :pdf
 ----------------------------