railties 3.1.12 → 3.2.0.rc1

data/guides/code/getting_started/test/fixtures/posts.yml

@@ -0,0 +1,11 @@
+# Read about fixtures at http://api.rubyonrails.org/classes/Fixtures.html
+
+one:
+  name: MyString
+  title: MyString
+  content: MyText
+
+two:
+  name: MyString
+  title: MyString
+  content: MyText

data/guides/code/getting_started/test/fixtures/tags.yml

@@ -0,0 +1,9 @@
+# Read about fixtures at http://api.rubyonrails.org/classes/Fixtures.html
+
+one:
+  name: MyString
+  post: 
+
+two:
+  name: MyString
+  post: 

data/guides/code/getting_started/test/functional/comments_controller_test.rb

@@ -0,0 +1,7 @@
+require 'test_helper'
+
+class CommentsControllerTest < ActionController::TestCase
+  # test "the truth" do
+  #   assert true
+  # end
+end

data/guides/code/getting_started/test/functional/home_controller_test.rb

@@ -0,0 +1,9 @@
+require 'test_helper'
+
+class HomeControllerTest < ActionController::TestCase
+  test "should get index" do
+    get :index
+    assert_response :success
+  end
+
+end

data/guides/code/getting_started/test/functional/posts_controller_test.rb

@@ -0,0 +1,49 @@
+require 'test_helper'
+
+class PostsControllerTest < ActionController::TestCase
+  setup do
+    @post = posts(:one)
+  end
+
+  test "should get index" do
+    get :index
+    assert_response :success
+    assert_not_nil assigns(:posts)
+  end
+
+  test "should get new" do
+    get :new
+    assert_response :success
+  end
+
+  test "should create post" do
+    assert_difference('Post.count') do
+      post :create, post: @post.attributes
+    end
+
+    assert_redirected_to post_path(assigns(:post))
+  end
+
+  test "should show post" do
+    get :show, id: @post.to_param
+    assert_response :success
+  end
+
+  test "should get edit" do
+    get :edit, id: @post.to_param
+    assert_response :success
+  end
+
+  test "should update post" do
+    put :update, id: @post.to_param, post: @post.attributes
+    assert_redirected_to post_path(assigns(:post))
+  end
+
+  test "should destroy post" do
+    assert_difference('Post.count', -1) do
+      delete :destroy, id: @post.to_param
+    end
+
+    assert_redirected_to posts_path
+  end
+end

data/guides/code/getting_started/test/performance/browsing_test.rb

@@ -0,0 +1,12 @@
+require 'test_helper'
+require 'rails/performance_test_help'
+
+class BrowsingTest < ActionDispatch::PerformanceTest
+  # Refer to the documentation for all available options
+  # self.profile_options = { :runs => 5, :metrics => [:wall_time, :memory]
+  #                          :output => 'tmp/performance', :formats => [:flat] }
+
+  def test_homepage
+    get '/'
+  end
+end

data/guides/code/getting_started/test/test_helper.rb

@@ -0,0 +1,13 @@
+ENV["RAILS_ENV"] = "test"
+require File.expand_path('../../config/environment', __FILE__)
+require 'rails/test_help'
+
+class ActiveSupport::TestCase
+  # Setup all fixtures in test/fixtures/*.(yml|csv) for all tests in alphabetical order.
+  #
+  # Note: You'll currently still have to declare fixtures explicitly in integration tests
+  # -- they do not yet inherit this setting
+  fixtures :all
+
+  # Add more helper methods to be used by all tests here...
+end

data/guides/code/getting_started/test/unit/comment_test.rb

@@ -0,0 +1,7 @@
+require 'test_helper'
+
+class CommentTest < ActiveSupport::TestCase
+  # test "the truth" do
+  #   assert true
+  # end
+end

data/guides/code/getting_started/test/unit/helpers/comments_helper_test.rb

@@ -0,0 +1,4 @@
+require 'test_helper'
+
+class CommentsHelperTest < ActionView::TestCase
+end

data/guides/code/getting_started/test/unit/helpers/home_helper_test.rb

@@ -0,0 +1,4 @@
+require 'test_helper'
+
+class HomeHelperTest < ActionView::TestCase
+end

data/guides/code/getting_started/test/unit/helpers/posts_helper_test.rb

@@ -0,0 +1,4 @@
+require 'test_helper'
+
+class PostsHelperTest < ActionView::TestCase
+end

data/guides/code/getting_started/test/unit/post_test.rb

@@ -0,0 +1,7 @@
+require 'test_helper'
+
+class PostTest < ActiveSupport::TestCase
+  # test "the truth" do
+  #   assert true
+  # end
+end

data/guides/code/getting_started/test/unit/tag_test.rb

@@ -0,0 +1,7 @@
+require 'test_helper'
+
+class TagTest < ActiveSupport::TestCase
+  # test "the truth" do
+  #   assert true
+  # end
+end

data/guides/rails_guides/generator.rb

@@ -137,7 +137,8 @@ module RailsGuides
 
         if guide =~ /\.html\.erb$/
           # Generate the special pages like the home.
-          result = view.render(:layout => 'layout', :file => guide)
+          # Passing a template handler in the template name is deprecated. So pass the file name without the extension.
+          result = view.render(:layout => 'layout', :file => $`)
         else
           body = File.read(File.join(source_dir, guide))
           body = set_header_section(body, view)

data/guides/source/3_0_release_notes.textile

@@ -59,12 +59,12 @@ The +config.gem+ method is gone and has been replaced by using +bundler+ and a +
 
 h4. Upgrade Process
 
-To help with the upgrade process, a plugin named "Rails Upgrade":http://github.com/jm/rails_upgrade has been created to automate part of it.
+To help with the upgrade process, a plugin named "Rails Upgrade":http://github.com/rails/rails_upgrade has been created to automate part of it.
 
 Simply install the plugin, then run +rake rails:upgrade:check+ to check your app for pieces that need to be updated (with links to information on how to update them). It also offers a task to generate a +Gemfile+ based on your current +config.gem+ calls and a task to generate a new routes file from your current one. To get the plugin, simply run the following:
 
 <shell>
-$ ruby script/plugin install git://github.com/jm/rails_upgrade.git
+$ ruby script/plugin install git://github.com/rails/rails_upgrade.git
 </shell>
 
 You can see an example of how that works at "Rails Upgrade is now an Official Plugin":http://omgbloglol.com/post/364624593/rails-upgrade-is-now-an-official-plugin

data/guides/source/3_1_release_notes.textile

@@ -21,113 +21,6 @@ Rails 3.1 requires Ruby 1.8.7 or higher. Support for all of the previous Ruby ve
 
 TIP: Note that Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails. Ruby Enterprise Edition have these fixed since release 1.8.7-2010.02 though. On the 1.9 front, Ruby 1.9.1 is not usable because it outright segfaults, so if you want to use 1.9.x jump on 1.9.2 for smooth sailing.
 
-h4. What to update in your apps
-
-The following changes are meant for upgrading your application to Rails 3.1.3, the latest 3.1.x version of Rails.
-
-h5. Gemfile
-
-Make the following changes to your +Gemfile+.
-
-<ruby>
-gem 'rails', '= 3.1.3'
-gem 'mysql2'
-
-# Needed for the new asset pipeline
-group :assets do
-  gem 'sass-rails',   "~> 3.1.5"
-  gem 'coffee-rails', "~> 3.1.1"
-  gem 'uglifier',     ">= 1.0.3"
-end
-
-# jQuery is the default JavaScript library in Rails 3.1
-gem 'jquery-rails'
-</ruby>
-
-h5. config/application.rb
-
-* The asset pipeline requires the following additions:
-
-<ruby>
-config.assets.enabled = true
-config.assets.version = '1.0'
-</ruby>
-
-* If your application is using the "/assets" route for a resource you may want change the prefix used for assets to avoid conflicts:
-
-<ruby>
-# Defaults to '/assets'
-config.assets.prefix = '/asset-files'
-</ruby>
-
-h5. config/environments/development.rb
-
-* Remove the RJS setting <tt>config.action_view.debug_rjs = true</tt>.
-
-* Add the following, if you enable the asset pipeline.
-
-<ruby>
-# Do not compress assets
-config.assets.compress = false
-
-# Expands the lines which load the assets
-config.assets.debug = true
-</ruby>
-
-h5. config/environments/production.rb
-
-* Again, most of the changes below are for the asset pipeline. You can read more about these in the "Asset Pipeline":asset_pipeline.html guide.
-
-<ruby>
-# Compress JavaScripts and CSS
-config.assets.compress = true
-
-# Don't fallback to assets pipeline if a precompiled asset is missed
-config.assets.compile = false
-
-# Generate digests for assets URLs
-config.assets.digest = true
-
-# Defaults to Rails.root.join("public/assets")
-# config.assets.manifest = YOUR_PATH
-
-# Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
-# config.assets.precompile += %w( search.js )
-
-
-# Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies.
-# config.force_ssl = true
-
-</ruby>
-
-h5. config/environments/test.rb
-
-<ruby>
-# Configure static asset server for tests with Cache-Control for performance
-config.serve_static_assets = true
-config.static_cache_control = "public, max-age=3600"
-</ruby>
-
-h5. config/initializers/wrap_parameters.rb
-
-* Add this file with the following contents, if you wish to wrap parameters into a nested hash. This is on by default in new applications.
-
-<ruby>
-# Be sure to restart your server when you modify this file.
-# This file contains settings for ActionController::ParamsWrapper which
-# is enabled by default.
-
-# Enable parameter wrapping for JSON. You can disable this by setting :format to an empty array.
-ActiveSupport.on_load(:action_controller) do
-  wrap_parameters :format => [:json]
-end
-
-# Disable root element in JSON by default.
-ActiveSupport.on_load(:active_record) do
-  self.include_root_in_json = false
-end
-</ruby>
-
 h3. Creating a Rails 3.1 application
 
 <shell>
@@ -352,7 +245,7 @@ class User < ActiveRecord::Base
   has_one :account
 end
 
-user.build_account{ |a| a.credit_limit => 100.0 }
+user.build_account{ |a| a.credit_limit = 100.0 }
 </ruby>
 
 * Added <tt>ActiveRecord::Base.attribute_names</tt> to return a list of attribute names. This will return an empty array if the model is abstract or the table does not exist.
@@ -378,7 +271,7 @@ Post.new(params[:post], :as => :admin)
 
 * +ConnectionManagement+ middleware is changed to clean up the connection pool after the rack body has been flushed.
 
-* Added an +update_column+ method on Active Record. This new method updates a given attribute on an object, skipping validations and callbacks. It is recommended to use +update_attribute+ unless you are sure you do not want to execute any callback, including the modification of the +updated_at+ column. It should not be called on new records.
+* Added an +update_column+ method on Active Record. This new method updates a given attribute on an object, skipping validations and callbacks. It is recommended to use +update_attributes+ or +update_attribute+ unless you are sure you do not want to execute any callback, including the modification of the +updated_at+ column. It should not be called on new records.
 
 * Associations with a +:through+ option can now use any association as the through or source association, including other associations which have a +:through+ option and +has_and_belongs_to_many+ associations.
 
@@ -422,7 +315,7 @@ end
 <ruby>
 class MyMigration < ActiveRecord::Migration
   def change
-    create_table(:horses) do
+    create_table(:horses) do |t|
       t.column :content, :text
       t.column :remind_at, :datetime
     end

data/guides/source/action_controller_overview.textile

@@ -16,7 +16,7 @@ h3. What Does a Controller Do?
 
 Action Controller is the C in MVC. After routing has determined which controller to use for a request, your controller is responsible for making sense of the request and producing the appropriate output. Luckily, Action Controller does most of the groundwork for you and uses smart conventions to make this as straightforward as possible.
 
-For most conventional RESTful applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
+For most conventional "RESTful":http://en.wikipedia.org/wiki/Representational_state_transfer applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
 
 A controller can thus be thought of as a middle man between models and views. It makes the model data available to the view so it can display that data to the user, and it saves or updates data from the user to the model.
 
@@ -166,10 +166,10 @@ h3. Session
 
 Your application has a session for each user in which you can store small amounts of data that will be persisted between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms:
 
-* CookieStore - Stores everything on the client.
-* DRbStore - Stores the data on a DRb server.
-* MemCacheStore - Stores the data in a memcache.
-* ActiveRecordStore - Stores the data in a database using Active Record.
+* ActionDispatch::Session::CookieStore - Stores everything on the client.
+* ActiveRecord::SessionStore - Stores the data in a database using Active Record.
+* ActionDispatch::Session::CacheStore - Stores the data in the Rails cache.
+* ActionDispatch::Session::MemCacheStore - Stores the data in a memcached cluster (this is a legacy implementation; consider using CacheStore instead).
 
 All session stores use a cookie to store a unique ID for each session (you must use a cookie, Rails will not allow you to pass the session ID in the URL as this is less secure).
 
@@ -177,6 +177,8 @@ For most stores this ID is used to look up the session data on the server, e.g.
 
 The CookieStore can store around 4kB of data -- much less than the others -- but this is usually enough. Storing large amounts of data in the session is discouraged no matter which session store your application uses. You should especially avoid storing complex objects (anything other than basic Ruby objects, the most common example being model instances) in the session, as the server might not be able to reassemble them between requests, which will result in an error.
 
+If your user sessions don't store critical data or don't need to be around for long periods (for instance if you just use the flash for messaging), you can consider using ActionDispatch::Session::CacheStore. This will store sessions using the cache implementation you have configured for your application. The advantage of this is that you can use your existing cache infrastructure for storing sessions without requiring any additional setup or administration. The downside, of course, is that the sessions will be ephemeral and could disappear at any time.
+
 Read more about session storage in the "Security Guide":security.html.
 
 If you need a different session storage mechanism, you can change it in the +config/initializers/session_store.rb+ file:
@@ -684,9 +686,11 @@ end
 
 This will read and stream the file 4kB at the time, avoiding loading the entire file into memory at once. You can turn off streaming with the +:stream+ option or adjust the block size with the +:buffer_size+ option.
 
+If +:type+ is not specified, it will be guessed from the file extension specified in +:filename+. If the content type is not registered for the extension, <tt>application/octet-stream</tt> will be used.
+
 WARNING: Be careful when using data coming from the client (params, cookies, etc.) to locate the file on disk, as this is a security risk that might allow someone to gain access to files they are not meant to see.
 
-TIP: It is not recommended that you stream static files through Rails if you can instead keep them in a public folder on your web server. It is much more efficient to let the user download the file directly using Apache or another web server, keeping the request from unnecessarily going through the whole Rails stack. Although if you do need the request to go through Rails for some reason, you can set the +:x_sendfile+ option to true, and Rails will let the web server handle sending the file to the user, freeing up the Rails process to do other things. Note that your web server needs to support the +X-Sendfile+ header for this to work.
+TIP: It is not recommended that you stream static files through Rails if you can instead keep them in a public folder on your web server. It is much more efficient to let the user download the file directly using Apache or another web server, keeping the request from unnecessarily going through the whole Rails stack.
 
 h4. RESTful Downloads
 
@@ -794,7 +798,7 @@ NOTE: Certain exceptions are only rescuable from the +ApplicationController+ cla
 
 h3. Force HTTPS protocol
 
-Sometime you might want to force a particular controller to only be accessible via an HTTPS protocol for security reason. Since Rails 3.1 you can now use +force_ssl+ method in your controller to enforce that:
+Sometime you might want to force a particular controller to only be accessible via an HTTPS protocol for security reasons. Since Rails 3.1 you can now use +force_ssl+ method in your controller to enforce that:
 
 <ruby>
 class DinnerController
@@ -813,9 +817,3 @@ end
 </ruby>
 
 Please note that if you found yourself adding +force_ssl+ to many controllers, you may found yourself wanting to force the whole application to use HTTPS instead. In that case, you can set the +config.force_ssl+ in your environment file.
-
-h3. Changelog
-
-* February 17, 2009: Yet another proofread by Xavier Noria.
-
-* November 4, 2008: First release version by Tore Darell

data/guides/source/action_mailer_basics.textile

@@ -362,21 +362,14 @@ When using named routes you only need to supply the +:host+:
 
 Email clients have no web context and so paths have no base URL to form complete web addresses. Thus, when using named routes only the "_url" variant makes sense.
 
-It is also possible to set a default host that will be used in all mailers by setting the +:host+ option in the +ActionMailer::Base.default_url_options+ hash as follows:
+It is also possible to set a default host that will be used in all mailers by setting the <tt>:host</tt> option as a configuration option in <tt>config/application.rb</tt>:
 
 <ruby>
-class UserMailer < ActionMailer::Base
-  default_url_options[:host] = "example.com"
-
-  def welcome_email(user)
-    @user = user
-    @url  = user_url(@user)
-    mail(:to => user.email,
-         :subject => "Welcome to My Awesome Site")
-  end
-end
+config.action_mailer.default_url_options = { :host => "example.com" }
 </ruby>
 
+If you use this setting, you should pass the <tt>:only_path => false</tt> option when using +url_for+. This will ensure that absolute URLs are generated because the +url_for+ view helper will, by default, generate relative URLs when a <tt>:host</tt> option isn't explicitly provided.
+
 h4. Sending Multipart Emails
 
 Action Mailer will automatically send multipart emails if you have different templates for the same action. So, for our UserMailer example, if you have +welcome_email.text.erb+ and +welcome_email.html.erb+ in +app/views/user_mailer+, Action Mailer will automatically send a multipart email with the HTML and text versions setup as different parts.
@@ -401,7 +394,7 @@ Will put the HTML part first, and the plain text part second.
 
 h4. Sending Emails with Attachments
 
-Attachments can be added by using the +attachment+ method:
+Attachments can be added by using the +attachments+ method:
 
 <ruby>
 class UserMailer < ActionMailer::Base
@@ -467,7 +460,7 @@ The following configuration options are best made in one of the environment file
 
 h4. Example Action Mailer Configuration
 
-An example would be adding the following to your appropriate <tt>config/environments/env.rb</tt> file:
+An example would be adding the following to your appropriate <tt>config/environments/$RAILS_ENV.rb</tt> file:
 
 <ruby>
 config.action_mailer.delivery_method = :sendmail
@@ -482,7 +475,7 @@ config.action_mailer.raise_delivery_errors = true
 
 h4. Action Mailer Configuration for GMail
 
-As Action Mailer now uses the Mail gem, this becomes as simple as adding to your <tt>config/environments/env.rb</tt> file:
+As Action Mailer now uses the Mail gem, this becomes as simple as adding to your <tt>config/environments/$RAILS_ENV.rb</tt> file:
 
 <ruby>
 config.action_mailer.delivery_method = :smtp
@@ -521,7 +514,3 @@ end
 </ruby>
 
 In the test we send the email and store the returned object in the +email+ variable. We then ensure that it was sent (the first assert), then, in the second batch of assertions, we ensure that the email does indeed contain what we expect.
-
-h3. Changelog
-
-* September 30, 2010: Fixed typos and reformatted Action Mailer configuration table for better understanding. "Jaime Iniesta":http://jaimeiniesta.com