diff options
Diffstat (limited to 'guides')
39 files changed, 1941 insertions, 1478 deletions
diff --git a/guides/code/getting_started/app/views/comments/_comment.html.erb b/guides/code/getting_started/app/views/comments/_comment.html.erb index 0cebe0bd96..3d2bc1590e 100644 --- a/guides/code/getting_started/app/views/comments/_comment.html.erb +++ b/guides/code/getting_started/app/views/comments/_comment.html.erb @@ -10,6 +10,6 @@ <p> <%= link_to 'Destroy Comment', [comment.post, comment], - :confirm => 'Are you sure?', - :method => :delete %> + :method => :delete, + :data => { :confirm => 'Are you sure?' } %> </p> diff --git a/guides/code/getting_started/app/views/posts/index.html.erb b/guides/code/getting_started/app/views/posts/index.html.erb index 7b72720d50..9a0e90eadc 100644 --- a/guides/code/getting_started/app/views/posts/index.html.erb +++ b/guides/code/getting_started/app/views/posts/index.html.erb @@ -17,7 +17,7 @@ <td><%= post.text %></td> <td><%= link_to 'Show', :action => :show, :id => post.id %> <td><%= link_to 'Edit', :action => :edit, :id => post.id %> - <td><%= link_to 'Destroy', { :action => :destroy, :id => post.id }, :method => :delete, :confirm => 'Are you sure?' %> + <td><%= link_to 'Destroy', { :action => :destroy, :id => post.id }, :method => :delete, :data => { :confirm => 'Are you sure?' } %> </tr> <% end %> </table> diff --git a/guides/code/getting_started/test/test_helper.rb b/guides/code/getting_started/test/test_helper.rb index 8bf1192ffe..3daca18a71 100644 --- a/guides/code/getting_started/test/test_helper.rb +++ b/guides/code/getting_started/test/test_helper.rb @@ -3,7 +3,7 @@ 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. + # Setup all fixtures in test/fixtures/*.yml 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 diff --git a/guides/rails_guides/textile_extensions.rb b/guides/rails_guides/textile_extensions.rb index 0a002a785f..1faddd4ca0 100644 --- a/guides/rails_guides/textile_extensions.rb +++ b/guides/rails_guides/textile_extensions.rb @@ -1,5 +1,3 @@ -require 'active_support/core_ext/object/inclusion' - module RedCloth::Formatters::HTML def emdash(opts) "--" diff --git a/guides/source/2_2_release_notes.textile b/guides/source/2_2_release_notes.textile index 3a0f2efbaf..eb4b32329b 100644 --- a/guides/source/2_2_release_notes.textile +++ b/guides/source/2_2_release_notes.textile @@ -118,9 +118,9 @@ h4. Transactional Migrations Historically, multiple-step Rails migrations have been a source of trouble. If something went wrong during a migration, everything before the error changed the database and everything after the error wasn't applied. Also, the migration version was stored as having been executed, which means that it couldn't be simply rerun by +rake db:migrate:redo+ after you fix the problem. Transactional migrations change this by wrapping migration steps in a DDL transaction, so that if any of them fail, the entire migration is undone. In Rails 2.2, transactional migrations are supported on PostgreSQL out of the box. The code is extensible to other database types in the future - and IBM has already extended it to support the DB2 adapter. -* Lead Contributor: "Adam Wiggins":http://adam.blog.heroku.com/ +* Lead Contributor: "Adam Wiggins":http://adam.heroku.com/ * More information: -** "DDL Transactions":http://adam.blog.heroku.com/past/2008/9/3/ddl_transactions/ +** "DDL Transactions":http://adam.heroku.com/past/2008/9/3/ddl_transactions/ ** "A major milestone for DB2 on Rails":http://db2onrails.com/2008/11/08/a-major-milestone-for-db2-on-rails/ h4. Connection Pooling diff --git a/guides/source/2_3_release_notes.textile b/guides/source/2_3_release_notes.textile index 15abba66ab..36f425574b 100644 --- a/guides/source/2_3_release_notes.textile +++ b/guides/source/2_3_release_notes.textile @@ -561,7 +561,7 @@ This will layer the changes from the template on top of whatever code the projec h4. Quieter Backtraces -Building on Thoughtbot's "Quiet Backtrace":http://www.thoughtbot.com/projects/quietbacktrace plugin, which allows you to selectively remove lines from +Test::Unit+ backtraces, Rails 2.3 implements +ActiveSupport::BacktraceCleaner+ and +Rails::BacktraceCleaner+ in core. This supports both filters (to perform regex-based substitutions on backtrace lines) and silencers (to remove backtrace lines entirely). Rails automatically adds silencers to get rid of the most common noise in a new application, and builds a +config/backtrace_silencers.rb+ file to hold your own additions. This feature also enables prettier printing from any gem in the backtrace. +Building on Thoughtbot's "Quiet Backtrace":https://github.com/thoughtbot/quietbacktrace plugin, which allows you to selectively remove lines from +Test::Unit+ backtraces, Rails 2.3 implements +ActiveSupport::BacktraceCleaner+ and +Rails::BacktraceCleaner+ in core. This supports both filters (to perform regex-based substitutions on backtrace lines) and silencers (to remove backtrace lines entirely). Rails automatically adds silencers to get rid of the most common noise in a new application, and builds a +config/backtrace_silencers.rb+ file to hold your own additions. This feature also enables prettier printing from any gem in the backtrace. h4. Faster Boot Time in Development Mode with Lazy Loading/Autoload diff --git a/guides/source/4_0_release_notes.textile b/guides/source/4_0_release_notes.textile index 8d13c59080..2f21f8cc71 100644 --- a/guides/source/4_0_release_notes.textile +++ b/guides/source/4_0_release_notes.textile @@ -12,9 +12,9 @@ TODO. This is a WIP guide. If you're upgrading an existing application, it's a great idea to have good test coverage before going in. You should also first upgrade to Rails 3.2 in case you haven't and make sure your application still runs as expected before attempting an update to Rails 4.0. Then take heed of the following changes: -h4. Rails 3.2 requires at least Ruby 1.9.3 +h4. Rails 4.0 requires at least Ruby 1.9.3 -Rails 3.2 requires Ruby 1.9.3 or higher. Support for all of the previous Ruby versions has been dropped officially and you should upgrade as early as possible. +Rails 4.0 requires Ruby 1.9.3 or higher. Support for all of the previous Ruby versions has been dropped officially and you should upgrade as early as possible. h4. What to update in your apps @@ -64,15 +64,23 @@ h3. Documentation h3. Railties +* Allow scaffold/model/migration generators to accept a <tt>polymorphic</tt> modifier for <tt>references</tt>/<tt>belongs_to</tt>, for instance + +<shell> +rails g model Product supplier:references{polymorphic} +</shell> + +will generate the model with <tt>belongs_to :supplier, polymorphic: true</tt> association and appropriate migration. + +* Set <tt>config.active_record.migration_error</tt> to <tt>:page_load</tt> for development. + * Add runner to <tt>Rails::Railtie</tt> as a hook called just after runner starts. * Add <tt>/rails/info/routes</tt> path which displays the same information as +rake routes+. * Improved +rake routes+ output for redirects. -* Load all environments available in config.paths["config/environments"]. - -* The application generator generates <tt>public/humans.txt</tt> with some basic data. +* Load all environments available in <tt>config.paths["config/environments"]</tt>. * Add <tt>config.queue_consumer</tt> to allow the default consumer to be configurable. @@ -92,23 +100,52 @@ console do end </ruby> -* Add convenience hide! method to Rails generators to hide current generator - namespace from showing when running rails generate. +* Add a convenience method <tt>hide!</tt> to Rails generators to hide the current generator namespace from showing when running <tt>rails generate</tt>. * Scaffold now uses +content_tag_for+ in <tt>index.html.erb</tt>. -* <tt>Rails::Plugin</tt> is removed. Instead of adding plugins to vendor/plugins use gems or bundler with path or git dependencies. +* <tt>Rails::Plugin</tt> is removed. Instead of adding plugins to <tt>vendor/plugins</tt>, use gems or bundler with path or git dependencies. h4(#railties_deprecations). Deprecations h3. Action Mailer -* No changes. +* Allow to set default Action Mailer options via <tt>config.action_mailer.default_options=</tt>. + +* Raise an <tt>ActionView::MissingTemplate</tt> exception when no implicit template could be found. + +* Asynchronously send messages via the Rails Queue. h3. Action Pack h4. Action Controller +* Add <tt>ActionController::Flash.add_flash_types</tt> method to allow people to register their own flash types. e.g.: + +<ruby> +class ApplicationController + add_flash_types :error, :warning +end +</ruby> + +If you add the above code, you can use <tt><%= error %></tt> in an erb, and <tt>redirect_to /foo, :error => 'message'</tt> in a controller. + +* Remove Active Model dependency from Action Pack. + +* Support unicode characters in routes. Route will be automatically escaped, so instead of manually escaping: + +<ruby> +get Rack::Utils.escape('こんにちは') => 'home#index' +</ruby> + +You just have to write the unicode route: + +<ruby> +get 'こんにちは' => 'home#index' +</ruby> + +* Return proper format on exceptions. + * Extracted redirect logic from <tt>ActionController::ForceSSL::ClassMethods.force_ssl</tt> into <tt>ActionController::ForceSSL#force_ssl_redirect</tt>. * URL path parameters with invalid encoding now raise <tt>ActionController::BadRequest</tt>. @@ -117,15 +154,15 @@ h4. Action Controller * +respond_to+ and +respond_with+ now raise <tt>ActionController::UnknownFormat</tt> instead of directly returning head 406. The exception is rescued and converted to 406 in the exception handling middleware. -* JSONP now uses mimetype <tt>application/javascript</tt> instead of <tt>application/json</tt>. +* JSONP now uses <tt>application/javascript</tt> instead of <tt>application/json</tt> as the MIME type. * Session arguments passed to process calls in functional tests are now merged into the existing session, whereas previously they would replace the existing session. This change may break some existing tests if they are asserting the exact contents of the session but should not break existing tests that only assert individual keys. -* Forms of persisted records use always PATCH (via the _method hack). +* Forms of persisted records use always PATCH (via the +_method+ hack). -* For resources, both PATCH and PUT are routed to the update action. +* For resources, both PATCH and PUT are routed to the +update+ action. -* Don't ignore +force_ssl+ in development. This is a change of behavior - use a :if condition to recreate the old behavior. +* Don't ignore +force_ssl+ in development. This is a change of behavior - use an <tt>:if</tt> condition to recreate the old behavior. <ruby> class AccountsController < ApplicationController @@ -139,62 +176,93 @@ end h5(#actioncontroller_deprecations). Deprecations -* Deprecated ActionController::Integration in favour of ActionDispatch::Integration +* Deprecated <tt>ActionController::Integration</tt> in favour of <tt>ActionDispatch::Integration</tt>. -* Deprecated ActionController::IntegrationTest in favour of ActionDispatch::IntegrationTest +* Deprecated <tt>ActionController::IntegrationTest</tt> in favour of <tt>ActionDispatch::IntegrationTest</tt>. -* Deprecated ActionController::PerformanceTest in favour of ActionDispatch::PerformanceTest +* Deprecated <tt>ActionController::PerformanceTest</tt> in favour of <tt>ActionDispatch::PerformanceTest</tt>. -* Deprecated ActionController::AbstractRequest in favour of ActionDispatch::Request +* Deprecated <tt>ActionController::AbstractRequest</tt> in favour of <tt>ActionDispatch::Request</tt>. -* Deprecated ActionController::Request in favour of ActionDispatch::Request +* Deprecated <tt>ActionController::Request</tt> in favour of <tt>ActionDispatch::Request</tt>. -* Deprecated ActionController::AbstractResponse in favour of ActionDispatch::Response +* Deprecated <tt>ActionController::AbstractResponse</tt> in favour of <tt>ActionDispatch::Response</tt>. -* Deprecated ActionController::Response in favour of ActionDispatch::Response +* Deprecated <tt>ActionController::Response</tt> in favour of <tt>ActionDispatch::Response</tt>. -* Deprecated ActionController::Routing in favour of ActionDispatch::Routing +* Deprecated <tt>ActionController::Routing</tt> in favour of <tt>ActionDispatch::Routing</tt>. h4. Action Dispatch +* Add Routing Concerns to declare common routes that can be reused inside others resources and routes. + +Code before: + +<ruby> +resources :messages do + resources :comments +end + +resources :posts do + resources :comments + resources :images, only: :index +end +</ruby> + +Code after: + +<ruby> +concern :commentable do + resources :comments +end + +concern :image_attachable do + resources :images, only: :index +end + +resources :messages, concerns: :commentable + +resources :posts, concerns: [:commentable, :image_attachable] +</ruby> + +* Show routes in exception page while debugging a <tt>RoutingError</tt> in development. + +* Include <tt>mounted_helpers</tt> (helpers for accessing mounted engines) in <tt>ActionDispatch::IntegrationTest</tt> by default. + * Added <tt>ActionDispatch::SSL</tt> middleware that when included force all the requests to be under HTTPS protocol. -* Copy literal route constraints to defaults so that url generation know about them. The copied constraints are :protocol, :subdomain, :domain, :host and :port. +* Copy literal route constraints to defaults so that url generation know about them. The copied constraints are <tt>:protocol</tt>, <tt>:subdomain</tt>, <tt>:domain</tt>, <tt>:host</tt> and <tt>:port</tt>. * Allows +assert_redirected_to+ to match against a regular expression. -* Add backtrace to development routing error page. +* Adds a backtrace to the routing error page in development. * +assert_generates+, +assert_recognizes+, and +assert_routing+ all raise +Assertion+ instead of +RoutingError+. * Allows the route helper root to take a string argument. For example, <tt>root 'pages#main'</tt> as a shortcut for <tt>root to: 'pages#main'</tt>. -* Adds support for the PATCH verb: - Request objects respond to patch?. - Routes have a new patch method, and understand :patch in the - existing places where a verb is configured, like :via. - New method patch available in functional tests. - If :patch is the default verb for updates, edits are - tunneled as PATCH rather than as PUT, and routing acts accordingly. - New method patch_via_redirect available in integration tests. +* Adds support for the PATCH verb: Request objects respond to <tt>patch?</tt>. Routes now have a new +patch+ method, and understand +:patch+ in the existing places where a verb is configured, like <tt>:via</tt>. Functional tests have a new method +patch+ and integration tests have a new method +patch_via_redirect+. +If <tt>:patch</tt> is the default verb for updates, edits are tunneled as <tt>PATCH</tt> rather than as <tt>PUT</tt> and routing acts accordingly. * Integration tests support the OPTIONS method. -* +expires_in+ accepts a +must_revalidate+ flag. If true, "must-revalidate" is added to the Cache-Control header. - -* Default responder will now always use your overridden block in respond_with to render your response. +* +expires_in+ accepts a +must_revalidate+ flag. If true, "must-revalidate" is added to the <tt>Cache-Control</tt> header. -* Turn off verbose mode of rack-cache, we still have X-Rack-Cache to check that info. +* Default responder will now always use your overridden block in <tt>respond_with</tt> to render your response. -* Include mounted_helpers (helpers for accessing mounted engines) in <tt>ActionDispatch::IntegrationTest</tt> by default. +* Turn off verbose mode of <tt>rack-cache</tt>, we still have <tt>X-Rack-Cache</tt> to check that info. h5(#actiondispatch_deprecations). Deprecations h4. Action View -* Make current object and counter (when it applies) variables accessible when rendering templates with :object / :collection. +* Remove Active Model dependency from Action Pack. + +* Allow to use <tt>mounted_helpers</tt> (helpers for accessing mounted engines) in <tt>ActionView::TestCase</tt>. + +* Make current object and counter (when it applies) variables accessible when rendering templates with <tt>:object</tt> or <tt>:collection</tt>. -* Allow to lazy load +default_form_builder+ by passing a String instead of a constant. +* Allow to lazy load +default_form_builder+ by passing a string instead of a constant. * Add index method to +FormBuilder+ class. @@ -204,16 +272,14 @@ h4. Action View * Remove <tt>:mouseover</tt> option from +image_tag+ helper. -* Templates without a handler extension now raises a deprecation warning but still defaults to ERb. In future releases, it will simply return the template content. +* Templates without a handler extension now raises a deprecation warning but still defaults to +ERb+. In future releases, it will simply return the template content. -* Add divider option to +grouped_options_for_select+ to generate a separator optgroup automatically, and deprecate prompt as third argument, in favor of using an options hash. +* Add a +divider+ option to +grouped_options_for_select+ to generate a separator optgroup automatically, and deprecate prompt as third argument, in favor of using an options hash. * Add +time_field+ and +time_field_tag+ helpers which render an <tt>input[type="time"]</tt> tag. * Removed old +text_helper+ apis for +highlight+, +excerpt+ and +word_wrap+. -* Allow to use mounted_helpers (helpers for accessing mounted engines) in <tt>ActionView::TestCase</tt>. - * Remove the leading \n added by textarea on +assert_select+. * Changed default value for <tt>config.action_view.embed_authenticity_token_in_remote_forms</tt> to false. This change breaks remote forms that need to work also without JavaScript, so if you need such behavior, you can either set it to true or explicitly pass <tt>:authenticity_token => true</tt> in form options. @@ -237,9 +303,9 @@ h4. Action View * Remove +button_to_function+ and +link_to_function+ helpers. -* truncate now always returns an escaped HTML-safe string. The option :escape can be used as false to not escape the result. +* +truncate+ now always returns an escaped HTML-safe string. The option <tt>:escape</tt> can be used as +false+ to not escape the result. -* truncate now accepts a block to show extra content when the text is truncated. +* +truncate+ now accepts a block to show extra content when the text is truncated. * Add +week_field+, +week_field_tag+, +month_field+, +month_field_tag+, +datetime_local_field+, +datetime_local_field_tag+, +datetime_field+ and +datetime_field_tag+ helpers. @@ -253,7 +319,7 @@ h4. Action View * Adds +image_url+, +javascript_url+, +stylesheet_url+, +audio_url+, +video_url+, and +font_url+ to assets tag helper. These URL helpers will return the full path to your assets. This is useful when you are going to reference this asset from external host. -* Allow +value_method+ and +text_method+ arguments from +collection_select+ and +options_from_collection_for_select+ to receive an object that responds to :call, such as a proc, to evaluate the option in the current element context. This works the same way with +collection_radio_buttons+ and +collection_check_boxes+. +* Allow +value_method+ and +text_method+ arguments from +collection_select+ and +options_from_collection_for_select+ to receive an object that responds to <tt>:call</tt> such as a proc, to evaluate the option in the current element context. This works the same way with +collection_radio_buttons+ and +collection_check_boxes+. * Add +date_field+ and +date_field_tag+ helpers which render an <tt>input[type="date"]</tt> tag. @@ -271,7 +337,7 @@ collection_check_boxes :post, :author_ids, Author.all, :id, :name The label/check_box pairs can be customized with a block. -* Add +collection_radio_buttons+ form helper, similar to collection_select: +* Add +collection_radio_buttons+ form helper, similar to +collection_select+: <ruby> collection_radio_buttons :post, :author_id, Author.all, :id, :name @@ -284,15 +350,15 @@ collection_radio_buttons :post, :author_id, Author.all, :id, :name The label/radio_button pairs can be customized with a block. -* +check_box+ with :form HTML5 attribute will now replicate the :form attribute to the hidden field as well. +* +check_box+ with an HTML5 attribute +:form+ will now replicate the +:form+ attribute to the hidden field as well. -* label form helper accepts :for => nil to not generate the attribute. +* label form helper accepts <tt>:for => nil</tt> to not generate the attribute. -* Add :format option to +number_to_percentage+. +* Add <tt>:format</tt> option to +number_to_percentage+. -* Add <tt>config.action_view.logger</tt> to configure logger for Action View. +* Add <tt>config.action_view.logger</tt> to configure logger for +Action View+. -* +check_box+ helper with :disabled => true will generate a disabled hidden field to conform with the HTML convention where disabled fields are not submitted with the form. This is a behavior change, previously the hidden tag had a value of the disabled checkbox. +* +check_box+ helper with <tt>:disabled => true</tt> will generate a +disabled+ hidden field to conform with the HTML convention where disabled fields are not submitted with the form. This is a behavior change, previously the hidden tag had a value of the disabled checkbox. * +favicon_link_tag+ helper will now use the favicon in <tt>app/assets</tt> by default. @@ -306,9 +372,149 @@ Moved into a separate gem <tt>sprockets-rails</tt>. h3. Active Record +* Add <tt>add_reference</tt> and <tt>remove_reference</tt> schema statements. Aliases, <tt>add_belongs_to</tt> and <tt>remove_belongs_to</tt> are acceptable. References are reversible. + +<ruby> +# Create a user_id column +add_reference(:products, :user) + +# Create a supplier_id, supplier_type columns and appropriate index +add_reference(:products, :supplier, polymorphic: true, index: true) + +# Remove polymorphic reference +remove_reference(:products, :supplier, polymorphic: true) +</ruby> + + +* Add <tt>:default</tt> and <tt>:null</tt> options to <tt>column_exists?</tt>. + +<ruby> +column_exists?(:testings, :taggable_id, :integer, null: false) +column_exists?(:testings, :taggable_type, :string, default: 'Photo') +</ruby> + +* <tt>ActiveRecord::Relation#inspect</tt> now makes it clear that you are dealing with a <tt>Relation</tt> object rather than an array: + +<ruby> +User.where(:age => 30).inspect +# => <ActiveRecord::Relation [#<User ...>, #<User ...>]> + +User.where(:age => 30).to_a.inspect +# => [#<User ...>, #<User ...>] +</ruby> + +if more than 10 items are returned by the relation, inspect will only show the first 10 followed by ellipsis. + +* Add <tt>:collation</tt> and <tt>:ctype</tt> support to PostgreSQL. These are available for PostgreSQL 8.4 or later. + +<yaml> +development: + adapter: postgresql + host: localhost + database: rails_development + username: foo + password: bar + encoding: UTF8 + collation: ja_JP.UTF8 + ctype: ja_JP.UTF8 +</yaml> + +* <tt>FinderMethods#exists?</tt> now returns <tt>false</tt> with the <tt>false</tt> argument. + +* Added support for specifying the precision of a timestamp in the postgresql adapter. So, instead of having to incorrectly specify the precision using the <tt>:limit</tt> option, you may use <tt>:precision</tt>, as intended. For example, in a migration: + +<ruby> +def change + create_table :foobars do |t| + t.timestamps :precision => 0 + end +end +</ruby> + +* Allow <tt>ActiveRecord::Relation#pluck</tt> to accept multiple columns. Returns an array of arrays containing the typecasted values: + +<ruby> +Person.pluck(:id, :name) +# SELECT people.id, people.name FROM people +# => [[1, 'David'], [2, 'Jeremy'], [3, 'Jose']] +</ruby> + +* Improve the derivation of HABTM join table name to take account of nesting. It now takes the table names of the two models, sorts them lexically and then joins them, stripping any common prefix from the second table name. Some examples: + +<plain> +Top level models (Category <=> Product) +Old: categories_products +New: categories_products + +Top level models with a global table_name_prefix (Category <=> Product) +Old: site_categories_products +New: site_categories_products + +Nested models in a module without a table_name_prefix method (Admin::Category <=> Admin::Product) +Old: categories_products +New: categories_products + +Nested models in a module with a table_name_prefix method (Admin::Category <=> Admin::Product) +Old: categories_products +New: admin_categories_products + +Nested models in a parent model (Catalog::Category <=> Catalog::Product) +Old: categories_products +New: catalog_categories_products + +Nested models in different parent models (Catalog::Category <=> Content::Page) +Old: categories_pages +New: catalog_categories_content_pages +</plain> + +* Move HABTM validity checks to <tt>ActiveRecord::Reflection</tt>. One side effect of this is to move when the exceptions are raised from the point of declaration to when the association is built. This is consistant with other association validity checks. + +* Added <tt>stored_attributes</tt> hash which contains the attributes stored using <tt>ActiveRecord::Store</tt>. This allows you to retrieve the list of attributes you've defined. + +<ruby> +class User < ActiveRecord::Base + store :settings, accessors: [:color, :homepage] +end + +User.stored_attributes[:settings] # [:color, :homepage] +</ruby> + +* <tt>composed_of</tt> was removed. You'll have to write your own accessor and mutator methods if you'd like to use value objects to represent some portion of your models. So, instead of: + +<ruby> +class Person < ActiveRecord::Base + composed_of :address, :mapping => [ %w(address_street street), %w(address_city city) ] +end +</ruby> + +you could write something like this: + +<ruby> +def address + @address ||= Address.new(address_street, address_city) +end + +def address=(address) + self[:address_street] = @address.street + self[:address_city] = @address.city + + @address = address +end +</ruby> + +* PostgreSQL default log level is now 'warning', to bypass the noisy notice messages. You can change the log level using the <tt>min_messages</tt> option available in your <tt>config/database.yml</tt>. + +* Add uuid datatype support to PostgreSQL adapter. + +* <tt>update_attribute</tt> has been removed. Use <tt>update_column</tt> if you want to bypass mass-assignment protection, validations, callbacks, and touching of updated_at. Otherwise please use <tt>update_attributes</tt>. + +* Added <tt>ActiveRecord::Migration.check_pending!</tt> that raises an error if migrations are pending. + +* Added <tt>#destroy!</tt> which acts like <tt>#destroy</tt> but will raise an <tt>ActiveRecord::RecordNotDestroyed</tt> exception instead of returning <tt>false</tt>. + * Allow blocks for count with <tt>ActiveRecord::Relation</tt>, to work similar as <tt>Array#count</tt>: <tt>Person.where("age > 26").count { |person| person.gender == 'female' }</tt> -* Added support to <tt>CollectionAssociation#delete</tt> for passing fixnum or string values as record ids. This finds the records responding to the id and executes delete on them. +* Added support to <tt>CollectionAssociation#delete</tt> for passing fixnum or string values as record ids. This finds the records responding to the ids and deletes them. <ruby> class Person < ActiveRecord::Base @@ -327,11 +533,11 @@ person.pets.delete(2, 3) # => [#<Pet id: 2>, #<Pet id: 3>] <ruby>store :settings, accessors: [ :color, :homepage ], coder: JSON</ruby> -* mysql and mysql2 connections will set SQL_MODE=STRICT_ALL_TABLES by default to avoid silent data loss. This can be disabled by specifying strict: false in your database.yml. +* +mysql+ and +mysql2+ connections will set <tt>SQL_MODE=STRICT_ALL_TABLES</tt> by default to avoid silent data loss. This can be disabled by specifying <tt>strict: false</tt> in <tt>config/database.yml</tt>. -* Added default order to first to assure consistent results among diferent database engines. Introduced take as a replacement to the old behavior of first. +* Added default order to <tt>ActiveRecord::Base#first</tt> to assure consistent results among diferent database engines. Introduced <tt>ActiveRecord::Base#take</tt> as a replacement to the old behavior. -* Added an :index option to automatically create indexes for references and belongs_to statements in migrations. The references and belongs_to methods now support an index option that receives either a boolean value or an options hash that is identical to options available to the add_index method: +* Added an <tt>:index</tt> option to automatically create indexes for +references+ and +belongs_to+ statements in migrations. This can be either a boolean or a hash that is identical to options available to the +add_index+ method: <ruby> create_table :messages do |t| @@ -352,7 +558,7 @@ Generators have also been updated to use the new syntax. * Added bang methods for mutating <tt>ActiveRecord::Relation</tt> objects. For example, while <tt>foo.where(:bar)</tt> will return a new object leaving foo unchanged, <tt>foo.where!(:bar)</tt> will mutate the foo object. -* Added #find_by and #find_by! to mirror the functionality provided by dynamic finders in a way that allows dynamic input more easily: +* Added <tt>#find_by</tt> and <tt>#find_by!</tt> to mirror the functionality provided by dynamic finders in a way that allows dynamic input more easily: <ruby> Post.find_by name: 'Spartacus', rating: 4 @@ -362,9 +568,9 @@ Post.find_by! name: 'Spartacus' * Added <tt>ActiveRecord::Base#slice</tt> to return a hash of the given methods with their names as keys and returned values as values. -* Remove IdentityMap - IdentityMap has never graduated to be an "enabled-by-default" feature, due to some inconsistencies with associations, as described in this commit: https://github.com/rails/rails/commit/302c912bf6bcd0fa200d964ec2dc4a44abe328a6. Hence the removal from the codebase, until such issues are fixed. +* Remove IdentityMap - IdentityMap has never graduated to be an "enabled-by-default" feature, due to some inconsistencies with associations, as described in this "commit":https://github.com/rails/rails/commit/302c912bf6bcd0fa200d964ec2dc4a44abe328a6. Hence the removal from the codebase, until such issues are fixed. -* Added a feature to dump/load internal state of SchemaCache instance because we want to boot rails more quickly when we have many models. +* Added a feature to dump/load internal state of +SchemaCache+ instance because we want to boot more quickly when we have many models. <ruby> # execute rake task. @@ -382,14 +588,14 @@ RAILS_ENV=production bundle exec rake db:schema:cache:clear => remove db/schema_cache.dump </ruby> -* Added support for partial indices to PostgreSQL adapter. +* Added support for partial indices to +PostgreSQL+ adapter. * The +add_index+ method now supports a +where+ option that receives a string with the partial index criteria. -* Implemented <tt>ActiveRecord::Relation#none</tt> method which returns a chainable relation with zero records (an instance of the NullRelation class). Any subsequent condition chained to the returned relation will continue generating an empty relation and will not fire any query to the database. - * Added the <tt>ActiveRecord::NullRelation</tt> class implementing the null object pattern for the Relation class. +* Implemented <tt>ActiveRecord::Relation#none</tt> method which returns a chainable relation with zero records (an instance of the +NullRelation+ class). Any subsequent condition chained to the returned relation will continue generating an empty relation and will not fire any query to the database. + * Added +create_join_table+ migration helper to create HABTM join tables. <ruby> @@ -401,7 +607,7 @@ create_join_table :products, :categories # end </ruby> -* The primary key is always initialized in the @attributes hash to nil (unless another value has been specified). +* The primary key is always initialized in the +@attributes+ hash to nil (unless another value has been specified). * In previous releases, the following would generate a single query with an OUTER JOIN comments, rather than two separate queries: @@ -482,27 +688,37 @@ The code to implement the deprecated features has been moved out to the +active_ Don't use this: - scope :red, where(color: 'red') - default_scope where(color: 'red') +<ruby> +scope :red, where(color: 'red') +default_scope where(color: 'red') +</ruby> Use this: - scope :red, -> { where(color: 'red') } - default_scope { where(color: 'red') } +<ruby> +scope :red, -> { where(color: 'red') } +default_scope { where(color: 'red') } +</ruby> The former has numerous issues. It is a common newbie gotcha to do the following: - scope :recent, where(published_at: Time.now - 2.weeks) +<ruby> +scope :recent, where(published_at: Time.now - 2.weeks) +</ruby> Or a more subtle variant: - scope :recent, -> { where(published_at: Time.now - 2.weeks) } - scope :recent_red, recent.where(color: 'red') +<ruby> +scope :recent, -> { where(published_at: Time.now - 2.weeks) } +scope :recent_red, recent.where(color: 'red') +</ruby> Eager scopes are also very complex to implement within Active Record, and there are still bugs. For example, the following does not do what you expect: - scope :remove_conditions, except(:where) - where(...).remove_conditions # => still has conditions +<ruby> +scope :remove_conditions, except(:where) +where(...).remove_conditions # => still has conditions +</ruby> * Added deprecation for the :dependent => :restrict association option. @@ -512,8 +728,36 @@ The code to implement the deprecated features has been moved out to the +active_ * New rails application would be generated with the config.active_record.dependent_restrict_raises = false in the application config. +* The migration generator now creates a join table with (commented) indexes every time the migration name contains the word "join_table". + h3. Active Model +* Changed <tt>AM::Serializers::JSON.include_root_in_json</tt> default value to false. Now, AM Serializers and AR objects have the same default behaviour. + +<ruby> +class User < ActiveRecord::Base; end + +class Person + include ActiveModel::Model + include ActiveModel::AttributeMethods + include ActiveModel::Serializers::JSON + + attr_accessor :name, :age + + def attributes + instance_values + end +end + +user.as_json +=> {"id"=>1, "name"=>"Konata Izumi", "age"=>16, "awesome"=>true} +# root is not included + +person.as_json +=> {"name"=>"Francesco", "age"=>22} +# root is not included +</ruby> + * Passing false hash values to +validates+ will no longer enable the corresponding validators. * +ConfirmationValidator+ error messages will attach to <tt>:#{attribute}_confirmation</tt> instead of +attribute+. @@ -528,10 +772,30 @@ h4(#activemodel_deprecations). Deprecations h3. Active Resource -* Active Resource is removed from Rails 4.0 and is now a separate gem. TODO: put a link to the gem here. +* Active Resource is removed from Rails 4.0 and is now a separate "gem":https://github.com/rails/activeresource. h3. Active Support +* Add default values to all <tt>ActiveSupport::NumberHelper</tt> methods, to avoid errors with empty locales or missing values. + +* <tt>Time#change</tt> now works with time values with offsets other than UTC or the local time zone. + +* Add <tt>Time#prev_quarter</tt> and <tt>Time#next_quarter</tt> short-hands for <tt>months_ago(3)</tt> and <tt>months_since(3)</tt>. + +* Remove obsolete and unused <tt>require_association</tt> method from dependencies. + +* Add <tt>:instance_accessor</tt> option for <tt>config_accessor</tt>. + +<ruby> +class User + include ActiveSupport::Configurable + config_accessor :allowed_access, instance_accessor: false +end + +User.new.allowed_access = true # => NoMethodError +User.new.allowed_access # => NoMethodError +</ruby> + * <tt>ActionView::Helpers::NumberHelper</tt> methods have been moved to <tt>ActiveSupport::NumberHelper</tt> and are now available via <tt>Numeric#to_s</tt>. * <tt>Numeric#to_s</tt> now accepts the formatting options :phone, :currency, :percentage, :delimited, :rounded, :human, and :human_size. @@ -582,6 +846,8 @@ h3. Active Support h4(#activesupport_deprecations). Deprecations +* <tt>ActiveSupport::Callbacks</tt>: deprecate usage of filter object with <tt>#before</tt> and <tt>#after</tt> methods as <tt>around</tt> callback. + * <tt>BufferedLogger</tt> is deprecated. Use <tt>ActiveSupport::Logger</tt> or the +logger+ from Ruby stdlib. * Deprecates the compatibility method <tt>Module#local_constant_names</tt> and use <tt>Module#local_constants</tt> instead (which returns symbols). diff --git a/guides/source/action_controller_overview.textile b/guides/source/action_controller_overview.textile index cc3350819b..3c828735ae 100644 --- a/guides/source/action_controller_overview.textile +++ b/guides/source/action_controller_overview.textile @@ -478,9 +478,9 @@ class ChangesController < ActionController::Base end </ruby> -Note that an around filter wraps also rendering. In particular, if in the example above the view itself reads from the database via a scope or whatever, it will do so within the transaction and thus present the data to preview. +Note that an around filter also wraps rendering. In particular, if in the example above, the view itself reads from the database (e.g. via a scope), it will do so within the transaction and thus present the data to preview. -They can choose not to yield and build the response themselves, in which case the action is not run. +You can choose not to yield and build the response yourself, in which case the action will not be run. h4. Other Ways to Use Filters diff --git a/guides/source/action_mailer_basics.textile b/guides/source/action_mailer_basics.textile index ebe774fbef..abfa68b76d 100644 --- a/guides/source/action_mailer_basics.textile +++ b/guides/source/action_mailer_basics.textile @@ -4,7 +4,7 @@ This guide should provide you with all you need to get started in sending and re endprologue. -WARNING. This Guide is based on Rails 3.2. Some of the code shown here will not work in earlier versions of Rails. +WARNING. This guide is based on Rails 3.2. Some of the code shown here will not work in earlier versions of Rails. h3. Introduction @@ -84,7 +84,7 @@ Create a file called +welcome_email.html.erb+ in +app/views/user_mailer/+. This </html> </erb> -It is also a good idea to make a text part for this email, to do this, create a file called +welcome_email.text.erb+ in +app/views/user_mailer/+: +It is also a good idea to make a text part for this email. To do this, create a file called +welcome_email.text.erb+ in +app/views/user_mailer/+: <erb> Welcome to example.com, <%= @user.name %> @@ -144,7 +144,7 @@ The method +welcome_email+ returns a <tt>Mail::Message</tt> object which can the NOTE: In previous versions of Rails, you would call +deliver_welcome_email+ or +create_welcome_email+. This has been deprecated in Rails 3.0 in favour of just calling the method name itself. -WARNING: Sending out an email should only take a fraction of a second, but if you are planning on sending out many emails, or you have a slow domain resolution service, you might want to investigate using a background process like Delayed Job. +WARNING: Sending out an email should only take a fraction of a second. If you are planning on sending out many emails, or you have a slow domain resolution service, you might want to investigate using a background process like Delayed Job. h4. Auto encoding header values @@ -152,14 +152,14 @@ Action Mailer now handles the auto encoding of multibyte characters inside of he If you are using UTF-8 as your character set, you do not have to do anything special, just go ahead and send in UTF-8 data to the address fields, subject, keywords, filenames or body of the email and Action Mailer will auto encode it into quoted printable for you in the case of a header field or Base64 encode any body parts that are non US-ASCII. -For more complex examples such as defining alternate character sets or self encoding text first, please refer to the Mail library. +For more complex examples such as defining alternate character sets or self-encoding text first, please refer to the Mail library. h4. Complete List of Action Mailer Methods There are just three methods that you need to send pretty much any email message: -* <tt>headers</tt> - Specifies any header on the email you want, you can pass a hash of header field names and value pairs, or you can call <tt>headers[:field_name] = 'value'</tt> -* <tt>attachments</tt> - Allows you to add attachments to your email, for example <tt>attachments['file-name.jpg'] = File.read('file-name.jpg')</tt> +* <tt>headers</tt> - Specifies any header on the email you want. You can pass a hash of header field names and value pairs, or you can call <tt>headers[:field_name] = 'value'</tt>. +* <tt>attachments</tt> - Allows you to add attachments to your email. For example, <tt>attachments['file-name.jpg'] = File.read('file-name.jpg')</tt>. * <tt>mail</tt> - Sends the actual email itself. You can pass in headers as a hash to the mail method as a parameter, mail will then create an email, either plain text, or multipart, depending on what email templates you have defined. h5. Custom Headers @@ -184,7 +184,7 @@ headers["X-Spam"] = value headers {"X-Spam" => value, "X-Special" => another_value} </ruby> -TIP: All <tt>X-Value</tt> headers per the RFC2822 can appear more than one time. If you want to delete an <tt>X-Value</tt> header, you need to assign it a value of <tt>nil</tt>. +TIP: All <tt>X-Value</tt> headers per the RFC2822 can appear more than once. If you want to delete an <tt>X-Value</tt> header, you need to assign it a value of <tt>nil</tt>. h5. Adding Attachments @@ -196,7 +196,7 @@ Adding attachments has been simplified in Action Mailer 3.0. attachments['filename.jpg'] = File.read('/path/to/filename.jpg') </ruby> -NOTE: Mail will automatically Base64 encode an attachment, if you want something different, pre-encode your content and pass in the encoded content and encoding in a +Hash+ to the +attachments+ method. +NOTE: Mail will automatically Base64 encode an attachment. If you want something different, pre-encode your content and pass in the encoded content and encoding in a +Hash+ to the +attachments+ method. * Pass the file name and specify headers and content and Action Mailer and Mail will use the settings you pass in. @@ -229,7 +229,7 @@ end <%= image_tag attachments['image.jpg'].url %> </erb> -* As this is a standard call to +image_tag+ you can pass in an options hash after the attachment url as you could for any other image: +* As this is a standard call to +image_tag+ you can pass in an options hash after the attachment URL as you could for any other image: <erb> <p>Hello there, this is our image</p> @@ -240,7 +240,7 @@ end h5. Sending Email To Multiple Recipients -It is possible to send email to one or more recipients in one email (for e.g. informing all admins of a new signup) by setting the list of emails to the <tt>:to</tt> key. The list of emails can be an array of email addresses or a single string with the addresses separated by commas. +It is possible to send email to one or more recipients in one email (e.g., informing all admins of a new signup) by setting the list of emails to the <tt>:to</tt> key. The list of emails can be an array of email addresses or a single string with the addresses separated by commas. <ruby> class AdminMailer < ActionMailer::Base @@ -457,6 +457,8 @@ The following configuration options are best made in one of the environment file |+delivery_method+|Defines a delivery method. Possible values are <tt>:smtp</tt> (default), <tt>:sendmail</tt>, <tt>:file</tt> and <tt>:test</tt>.| |+perform_deliveries+|Determines whether deliveries are actually carried out when the +deliver+ method is invoked on the Mail message. By default they are, but this can be turned off to help functional testing.| |+deliveries+|Keeps an array of all the emails sent out through the Action Mailer with delivery_method :test. Most useful for unit and functional testing.| +|+async+|Setting this flag will turn on asynchronous message sending, message rendering and delivery will be pushed to <tt>Rails.queue</tt> for processing.| +|+default_options+|Allows you to set default values for the <tt>mail</tt> method options (<tt>:from</tt>, <tt>:reply_to</tt>, etc.).| h4. Example Action Mailer Configuration @@ -471,6 +473,7 @@ config.action_mailer.delivery_method = :sendmail # } config.action_mailer.perform_deliveries = true config.action_mailer.raise_delivery_errors = true +config.action_mailer.default_options = {from: "no-replay@example.org"} </ruby> h4. Action Mailer Configuration for GMail @@ -507,10 +510,40 @@ class UserMailerTest < ActionMailer::TestCase # Test the body of the sent email contains what we expect it to assert_equal [user.email], email.to assert_equal "Welcome to My Awesome Site", email.subject - assert_match(/<h1>Welcome to example.com, #{user.name}<\/h1>/, email.encoded) - assert_match(/Welcome to example.com, #{user.name}/, email.encoded) + assert_match "<h1>Welcome to example.com, #{user.name}</h1>", email.body.to_s + assert_match "you have joined to example.com community", email.body.to_s end 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. Asynchronous + +You can turn on application-wide asynchronous message sending by adding to your <tt>config/application.rb</tt> file: + +<ruby> +config.action_mailer.async = true +</ruby> + +Alternatively you can turn on async within specific mailers: + +<ruby> +class WelcomeMailer < ActionMailer::Base + self.async = true +end +</ruby> + +h4. Custom Queues + +If you need a different queue than <tt>Rails.queue</tt> for your mailer you can override <tt>ActionMailer::Base#queue</tt>: + +<ruby> +class WelcomeMailer < ActionMailer::Base + def queue + MyQueue.new + end +end +</ruby> + +Your custom queue should expect a job that responds to <tt>#run</tt>. diff --git a/guides/source/action_view_overview.textile b/guides/source/action_view_overview.textile index fdfa97effa..1fd98a5bbe 100644 --- a/guides/source/action_view_overview.textile +++ b/guides/source/action_view_overview.textile @@ -785,7 +785,7 @@ h5. content_for Calling +content_for+ stores a block of markup in an identifier for later use. You can make subsequent calls to the stored content in other templates or the layout by passing the identifier as an argument to +yield+. -For example, let's say we have a standard application layout, but also a special page that requires certain Javascript that the rest of the site doesn't need. We can use +content_for+ to include this Javascript on our special page without fattening up the rest of the site. +For example, let's say we have a standard application layout, but also a special page that requires certain JavaScript that the rest of the site doesn't need. We can use +content_for+ to include this JavaScript on our special page without fattening up the rest of the site. *app/views/layouts/application.html.erb* diff --git a/guides/source/active_model_basics.textile b/guides/source/active_model_basics.textile index d373f4ac85..2c30ddb84c 100644 --- a/guides/source/active_model_basics.textile +++ b/guides/source/active_model_basics.textile @@ -1,18 +1,18 @@ h2. Active Model Basics -This guide should provide you with all you need to get started using model classes. Active Model allow for Action Pack helpers to interact with non-ActiveRecord models. Active Model also helps building custom ORMs for use outside of the Rails framework. +This guide should provide you with all you need to get started using model classes. Active Model allows for Action Pack helpers to interact with non-ActiveRecord models. Active Model also helps building custom ORMs for use outside of the Rails framework. endprologue. -WARNING. This Guide is based on Rails 3.0. Some of the code shown here will not work in earlier versions of Rails. +WARNING. This guide is based on Rails 3.0. Some of the code shown here will not work in earlier versions of Rails. h3. Introduction -Active Model is a library containing various modules used in developing frameworks that need to interact with the Rails Action Pack library. Active Model provides a known set of interfaces for usage in classes. Some of modules are explained below - +Active Model is a library containing various modules used in developing frameworks that need to interact with the Rails Action Pack library. Active Model provides a known set of interfaces for usage in classes. Some of modules are explained below. h4. AttributeMethods -AttributeMethods module can add custom prefixes and suffixes on methods of a class. It is used by defining the prefixes and suffixes, which methods on the object will use them. +The AttributeMethods module can add custom prefixes and suffixes on methods of a class. It is used by defining the prefixes and suffixes, which methods on the object will use them. <ruby> class Person @@ -92,7 +92,7 @@ person.to_param #=> nil h4. Dirty -An object becomes dirty when an object is gone through one or more changes to its attributes and not yet saved. This gives the ability to check whether an object has been changed or not. It also has attribute based accessor methods. Lets consider a Person class with attributes first_name and last_name +An object becomes dirty when it has gone through one or more changes to its attributes and has not been saved. This gives the ability to check whether an object has been changed or not. It also has attribute based accessor methods. Let's consider a Person class with attributes first_name and last_name <ruby> require 'active_model' @@ -168,7 +168,7 @@ Track what was the previous value of the attribute. person.first_name_was #=> "First Name" </ruby> -Track both previous and current value of the changed attribute. Returns an array if changed else returns nil +Track both previous and current value of the changed attribute. Returns an array if changed, else returns nil. <ruby> #attr_name_change @@ -187,7 +187,7 @@ class Person attr_accessor :name, :email, :token validates :name, :presence => true - validates_format_of :email, :with => /^([^\s]+)((?:[-a-z0-9]\.)[a-z]{2,})$/i + validates_format_of :email, :with => /\A([^\s]+)((?:[-a-z0-9]\.)[a-z]{2,})\z/i validates! :token, :presence => true end diff --git a/guides/source/active_record_querying.textile b/guides/source/active_record_querying.textile index 4b14671efc..80c9260a0d 100644 --- a/guides/source/active_record_querying.textile +++ b/guides/source/active_record_querying.textile @@ -12,8 +12,6 @@ This guide covers different ways to retrieve data from the database using Active endprologue. -WARNING. This Guide is based on Rails 3.0. Some of the code shown here will not work in other versions of Rails. - If you're used to using raw SQL to find database records, then you will generally find that there are better ways to carry out the same operations in Rails. Active Record insulates you from the need to use SQL in most cases. Code examples throughout this guide will refer to one or more of the following models: @@ -53,20 +51,29 @@ h3. Retrieving Objects from the Database To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL. The methods are: -* +where+ -* +select+ +* +bind+ +* +create_with+ +* +eager_load+ +* +extending+ +* +from+ * +group+ -* +order+ -* +reorder+ -* +reverse_order+ -* +limit+ -* +offset+ -* +joins+ +* +having+ * +includes+ +* +joins+ +* +limit+ * +lock+ +* +none+ +* +offset+ +* +order+ +* +none+ +* +preload+ * +readonly+ -* +from+ -* +having+ +* +references+ +* +reorder+ +* +reverse_order+ +* +select+ +* +uniq+ +* +where+ All of the above methods return an instance of <tt>ActiveRecord::Relation</tt>. @@ -488,7 +495,7 @@ This code will generate SQL like this: SELECT * FROM clients WHERE (clients.orders_count IN (1,3,5)) </sql> -h3. Ordering +h3(#ordering). Ordering To retrieve records from the database in a specific order, you can use the +order+ method. @@ -514,6 +521,13 @@ Client.order("orders_count ASC, created_at DESC") Client.order("orders_count ASC", "created_at DESC") </ruby> +If you want to call +order+ multiple times e.g. in different context, new order will prepend previous one + +<ruby> +Client.order("orders_count ASC").order("created_at DESC") +# SELECT * FROM clients ORDER BY created_at DESC, orders_count ASC +</ruby> + h3. Selecting Specific Fields By default, <tt>Model.find</tt> selects all the fields from the result set using +select *+. @@ -609,8 +623,8 @@ And this will give you a single +Order+ object for each date where there are ord The SQL that would be executed would be something like this: <sql> -SELECT date(created_at) as ordered_date, sum(price) as total_price -FROM orders +SELECT date(created_at) as ordered_date, sum(price) as total_price +FROM orders GROUP BY date(created_at) </sql> @@ -627,9 +641,9 @@ Order.select("date(created_at) as ordered_date, sum(price) as total_price").grou The SQL that would be executed would be something like this: <sql> -SELECT date(created_at) as ordered_date, sum(price) as total_price -FROM orders -GROUP BY date(created_at) +SELECT date(created_at) as ordered_date, sum(price) as total_price +FROM orders +GROUP BY date(created_at) HAVING sum(price) > 100 </sql> @@ -1039,7 +1053,7 @@ Even though Active Record lets you specify conditions on the eager loaded associ However if you must do this, you may use +where+ as you would normally. <ruby> -Post.includes(:comments).where("comments.visible", true) +Post.includes(:comments).where("comments.visible" => true) </ruby> This would generate a query which contains a +LEFT OUTER JOIN+ whereas the +joins+ method would generate one using the +INNER JOIN+ function instead. @@ -1128,21 +1142,6 @@ Using a class method is the preferred way to accept arguments for scopes. These category.posts.created_before(time) </ruby> -h4. Working with scopes - -Where a relational object is required, the +scoped+ method may come in handy. This will return an +ActiveRecord::Relation+ object which can have further scoping applied to it afterwards. A place where this may come in handy is on associations - -<ruby> -client = Client.find_by_first_name("Ryan") -orders = client.orders.scoped -</ruby> - -With this new +orders+ object, we are able to ascertain that this object can have more scopes applied to it. For instance, if we wanted to return orders only in the last 30 days at a later point. - -<ruby> -orders.where("created_at > ?", 30.days.ago) -</ruby> - h4. Applying a default scope If we wish for a scope to be applied across all queries to the model we can use the +default_scope+ method within the model itself. @@ -1286,26 +1285,36 @@ Client.connection.select_all("SELECT * FROM clients WHERE id = '1'") h3. +pluck+ -<tt>pluck</tt> can be used to query a single column from the underlying table of a model. It accepts a column name as argument and returns an array of values of the specified column with the corresponding data type. +<tt>pluck</tt> can be used to query a single or multiple columns from the underlying table of a model. It accepts a list of column names as argument and returns an array of values of the specified columns with the corresponding data type. <ruby> Client.where(:active => true).pluck(:id) # SELECT id FROM clients WHERE active = 1 +# => [1, 2, 3] Client.uniq.pluck(:role) # SELECT DISTINCT role FROM clients +# => ['admin', 'member', 'guest'] + +Client.pluck(:id, :name) +# SELECT clients.id, clients.name FROM clients +# => [[1, 'David'], [2, 'Jeremy'], [3, 'Jose']] </ruby> +pluck+ makes it possible to replace code like <ruby> Client.select(:id).map { |c| c.id } +# or +Client.select(:id).map { |c| [c.id, c.name] } </ruby> with <ruby> Client.pluck(:id) +# or +Client.pluck(:id, :name) </ruby> h3. +ids+ diff --git a/guides/source/active_record_validations_callbacks.textile b/guides/source/active_record_validations_callbacks.textile index f49d91fd3c..b866337e3f 100644 --- a/guides/source/active_record_validations_callbacks.textile +++ b/guides/source/active_record_validations_callbacks.textile @@ -86,6 +86,7 @@ The following methods skip validations, and will save the object to the database * +update_all+ * +update_attribute+ * +update_column+ +* +update_columns+ * +update_counters+ Note that +save+ also has the ability to skip validations if passed +:validate => false+ as argument. This technique should be used with caution. @@ -373,6 +374,8 @@ class LineItem < ActiveRecord::Base end </ruby> +If you validate the presence of an object associated via a +has_one+ or +has_many+ relationship, it will check that the object is neither +blank?+ nor +marked_for_destruction?+. + Since +false.blank?+ is true, if you want to validate the presence of a boolean field you should use <tt>validates :field_name, :inclusion => { :in => [true, false] }</tt>. The default error message is "_can't be empty_". @@ -529,6 +532,16 @@ end Person.new.valid? => ActiveModel::StrictValidationFailed: Name can't be blank </ruby> +There is also an ability to pass custom exception to +:strict+ option + +<ruby> +class Person < ActiveRecord::Base + validates :token, :presence => true, :uniqueness => true, :strict => TokenGenerationException +end + +Person.new.valid? => TokenGenerationException: Token can't be blank +</ruby> + h3. Conditional Validation Sometimes it will make sense to validate an object just when a given predicate is satisfied. You can do that by using the +:if+ and +:unless+ options, which can take a symbol, a string, a +Proc+ or an +Array+. You may use the +:if+ option when you want to specify when the validation *should* happen. If you want to specify when the validation *should not* happen, then you may use the +:unless+ option. @@ -1082,6 +1095,7 @@ Just as with validations, it is also possible to skip callbacks. These methods s * +toggle+ * +touch+ * +update_column+ +* +update_columns+ * +update_all+ * +update_counters+ diff --git a/guides/source/active_support_core_extensions.textile b/guides/source/active_support_core_extensions.textile index 011a702901..109228f8c7 100644 --- a/guides/source/active_support_core_extensions.textile +++ b/guides/source/active_support_core_extensions.textile @@ -1325,6 +1325,41 @@ that amount of leading whitespace. NOTE: Defined in +active_support/core_ext/string/strip.rb+. +h4. +indent+ + +Indents the lines in the receiver: + +<ruby> +<<EOS.indent(2) +def some_method + some_code +end +EOS +# => + def some_method + some_code + end +</ruby> + +The second argument, +indent_string+, specifies which indent string to use. The default is +nil+, which tells the method to make an educated guess peeking at the first indented line, and fallback to a space if there is none. + +<ruby> +" foo".indent(2) # => " foo" +"foo\n\t\tbar".indent(2) # => "\t\tfoo\n\t\t\t\tbar" +"foo".indent(2, "\t") # => "\t\tfoo" +</ruby> + +While +indent_string+ is tipically one space or tab, it may be any string. + +The third argument, +indent_empty_lines+, is a flag that says whether empty lines should be indented. Default is false. + +<ruby> +"foo\n\nbar".indent(2) # => " foo\n\n bar" +"foo\n\nbar".indent(2, nil, true) # => " foo\n \n bar" +</ruby> + +The +indent!+ method performs indentation in-place. + h4. Access h5. +at(position)+ @@ -1857,16 +1892,24 @@ h4. Formatting Enables the formatting of numbers in a variety of ways. Produce a string representation of a number as a telephone number: + <ruby> -5551234.to_s(:phone) # => 555-1234 -1235551234.to_s(:phone) # => 123-555-1234 -1235551234.to_s(:phone, :area_code => true) # => (123) 555-1234 -1235551234.to_s(:phone, :delimiter => " ") # => 123 555 1234 -1235551234.to_s(:phone, :area_code => true, :extension => 555) # => (123) 555-1234 x 555 -1235551234.to_s(:phone, :country_code => 1) # => +1-123-555-1234 +5551234.to_s(:phone) +# => 555-1234 +1235551234.to_s(:phone) +# => 123-555-1234 +1235551234.to_s(:phone, :area_code => true) +# => (123) 555-1234 +1235551234.to_s(:phone, :delimiter => " ") +# => 123 555 1234 +1235551234.to_s(:phone, :area_code => true, :extension => 555) +# => (123) 555-1234 x 555 +1235551234.to_s(:phone, :country_code => 1) +# => +1-123-555-1234 </ruby> Produce a string representation of a number as currency: + <ruby> 1234567890.50.to_s(:currency) # => $1,234,567,890.50 1234567890.506.to_s(:currency) # => $1,234,567,890.51 @@ -1874,14 +1917,20 @@ Produce a string representation of a number as currency: </ruby> Produce a string representation of a number as a percentage: + <ruby> -100.to_s(:percentage) # => 100.000% -100.to_s(:percentage, :precision => 0) # => 100% -1000.to_s(:percentage, :delimiter => '.', :separator => ',') # => 1.000,000% -302.24398923423.to_s(:percentage, :precision => 5) # => 302.24399% +100.to_s(:percentage) +# => 100.000% +100.to_s(:percentage, :precision => 0) +# => 100% +1000.to_s(:percentage, :delimiter => '.', :separator => ',') +# => 1.000,000% +302.24398923423.to_s(:percentage, :precision => 5) +# => 302.24399% </ruby> Produce a string representation of a number in delimited form: + <ruby> 12345678.to_s(:delimited) # => 12,345,678 12345678.05.to_s(:delimited) # => 12,345,678.05 @@ -1891,33 +1940,36 @@ Produce a string representation of a number in delimited form: </ruby> Produce a string representation of a number rounded to a precision: + <ruby> -111.2345.to_s(:rounded) # => 111.235 -111.2345.to_s(:rounded, :precision => 2) # => 111.23 -13.to_s(:rounded, :precision => 5) # => 13.00000 -389.32314.to_s(:rounded, :precision => 0) # => 389 -111.2345.to_s(:rounded, :significant => true) # => 111 +111.2345.to_s(:rounded) # => 111.235 +111.2345.to_s(:rounded, :precision => 2) # => 111.23 +13.to_s(:rounded, :precision => 5) # => 13.00000 +389.32314.to_s(:rounded, :precision => 0) # => 389 +111.2345.to_s(:rounded, :significant => true) # => 111 </ruby> Produce a string representation of a number as a human-readable number of bytes: + <ruby> -123.to_s(:human_size) # => 123 Bytes -1234.to_s(:human_size) # => 1.21 KB -12345.to_s(:human_size) # => 12.1 KB -1234567.to_s(:human_size) # => 1.18 MB -1234567890.to_s(:human_size) # => 1.15 GB -1234567890123.to_s(:human_size) # => 1.12 TB +123.to_s(:human_size) # => 123 Bytes +1234.to_s(:human_size) # => 1.21 KB +12345.to_s(:human_size) # => 12.1 KB +1234567.to_s(:human_size) # => 1.18 MB +1234567890.to_s(:human_size) # => 1.15 GB +1234567890123.to_s(:human_size) # => 1.12 TB </ruby> Produce a string representation of a number in human-readable words: + <ruby> -123.to_s(:human) # => "123" -1234.to_s(:human) # => "1.23 Thousand" -12345.to_s(:human) # => "12.3 Thousand" -1234567.to_s(:human) # => "1.23 Million" -1234567890.to_s(:human) # => "1.23 Billion" -1234567890123.to_s(:human) # => "1.23 Trillion" -1234567890123456.to_s(:human) # => "1.23 Quadrillion" +123.to_s(:human) # => "123" +1234.to_s(:human) # => "1.23 Thousand" +12345.to_s(:human) # => "12.3 Thousand" +1234567.to_s(:human) # => "1.23 Million" +1234567890.to_s(:human) # => "1.23 Billion" +1234567890123.to_s(:human) # => "1.23 Trillion" +1234567890123456.to_s(:human) # => "1.23 Quadrillion" </ruby> NOTE: Defined in +active_support/core_ext/numeric/formatting.rb+. @@ -2469,6 +2521,7 @@ To do so, the method loops over the pairs and builds nodes that depend on the _v * If +value+ responds to +to_xml+ the method is invoked with +key+ as <tt>:root</tt>. * Otherwise, a node with +key+ as tag is created with a string representation of +value+ as text node. If +value+ is +nil+ an attribute "nil" set to "true" is added. Unless the option <tt>:skip_types</tt> exists and is true, an attribute "type" is added as well according to the following mapping: + <ruby> XML_TYPE_NAMES = { "Symbol" => "symbol", @@ -2765,27 +2818,7 @@ The method +assert_valid_keys+ receives an arbitrary number of arguments, and ch {:a => 1}.assert_valid_keys("a") # ArgumentError </ruby> -Active Record does not accept unknown options when building associations for example. It implements that control via +assert_valid_keys+: - -<ruby> -mattr_accessor :valid_keys_for_has_many_association -@@valid_keys_for_has_many_association = [ - :class_name, :table_name, :foreign_key, :primary_key, - :dependent, - :select, :conditions, :include, :order, :group, :having, :limit, :offset, - :as, :through, :source, :source_type, - :uniq, - :finder_sql, :counter_sql, - :before_add, :after_add, :before_remove, :after_remove, - :extend, :readonly, - :validate, :inverse_of -] - -def create_has_many_reflection(association_id, options, &extension) - options.assert_valid_keys(valid_keys_for_has_many_association) - ... -end -</ruby> +Active Record does not accept unknown options when building associations, for example. It implements that control via +assert_valid_keys+. NOTE: Defined in +active_support/core_ext/hash/keys.rb+. @@ -3027,6 +3060,27 @@ Date.new(2000, 1, 31).next_month # => Tue, 29 Feb 2000 +prev_month+ is aliased to +last_month+. +h6. +prev_quarter+, +next_quarter+ + +Same as +prev_month+ and +next_month+. It returns the date with the same day in the previous or next quarter: + +<ruby> +t = Time.local(2010, 5, 8) # => Sat, 08 May 2010 +t.prev_quarter # => Mon, 08 Feb 2010 +t.next_quarter # => Sun, 08 Aug 2010 +</ruby> + +If such a day does not exist, the last day of the corresponding month is returned: + +<ruby> +Time.local(2000, 7, 31).prev_quarter # => Sun, 30 Apr 2000 +Time.local(2000, 5, 31).prev_quarter # => Tue, 29 Feb 2000 +Time.local(2000, 10, 31).prev_quarter # => Mon, 30 Oct 2000 +Time.local(2000, 11, 31).next_quarter # => Wed, 28 Feb 2001 +</ruby> + ++prev_quarter+ is aliased to +last_quarter+. + h6. +beginning_of_week+, +end_of_week+ The methods +beginning_of_week+ and +end_of_week+ return the dates for the diff --git a/guides/source/ajax_on_rails.textile b/guides/source/ajax_on_rails.textile index bfd007490a..67b0c9f0d3 100644 --- a/guides/source/ajax_on_rails.textile +++ b/guides/source/ajax_on_rails.textile @@ -1,6 +1,8 @@ h2. AJAX on Rails -This guide covers the built-in Ajax/JavaScript functionality of Rails (and more); it will enable you to create rich and dynamic AJAX applications with ease! We will cover the following topics: +This guide covers the built-in Ajax/JavaScript functionality of Rails (and more); +it will enable you to create rich and dynamic AJAX applications with ease! We will +cover the following topics: * Quick introduction to AJAX and related technologies * Unobtrusive JavaScript helpers with drivers for Prototype, jQuery etc @@ -10,34 +12,99 @@ endprologue. h3. Hello AJAX - a Quick Intro -You'll need the basics of DOM, HTTP requests and other topics discussed here to really understand Ajax on Rails. +AJAX is about updating parts of a web page without reloading the page. An AJAX +call happens as a response to an event, like when the page finished loading or +when a user clicks on an element. For example, let say you click on a link, which +would usually take you to a new page, but instead of doing that, an asynchronous +HTTP request is made and the response is evaluated with JavaScript. That way the +page is not reloaded and new information can be dynamically included in the page. +The way that happens is by inserting, removing or changing parts of the DOM. The +DOM, or Document Object Model, is a convention to represent the HTML document as +a set of nodes that contain other nodes. For example, a list of names is represented +as a +ul+ element node containing several +li+ element nodes. An AJAX call can +be made to obtain a new list item to include, and append it inside a +li+ node to +the +ul+ node. h4. Asynchronous JavaScript + XML -Basic terminology, new style of creating web apps +AJAX means Asynchronous JavaScript + XML. Asynchronous means that the page is not +reloaded, the request made is separate from the regular page request. JavaScript +is used to evaluate the response and the XML part is a bit misleading as XML is +not required, you respond to the HTTP request with JSON or regular HTML as well. h4. The DOM -basics of the DOM, how is it built, properties, features, why is it central to AJAX +The DOM (Document Object Model) is a convention to represent HTML (or XML) +documents, as a set of nodes that act as objects and contain other nodes. You can +have a +div+ element that contains other +div+ elements as well as +p+ elements +that contain text. h4. Standard HTML communication vs AJAX -How do 'standard' and AJAX requests differ, why does this matter for understanding AJAX on Rails (tie in for *_remote helpers, the next section) +In regular HTML comunications, when you click on a link, the browser makes an HTTP ++GET+ request, the server responds with a new HTML document that the browsers renders +and then replaces the previous one. The same thing happens when you click a button to +submit a form, except that you make and HTTP +POST+ request, but you also get a new +HTML document that the browser renders and replaces the current one. In AJAX +communications, the request is separate, and the response is evaluated in JavaScript +instead of rendered by the browser. That way you can have more control over the content +that gets returned, and the page is not reloaded. h3. Built-in Rails Helpers -Rails 3.1 ships with "jQuery":http://jquery.com as the default JavaScript library. The Gemfile contains <tt>gem 'jquery-rails'</tt> which makes the jQuery files available to the application automatically. This can be accessed as: +Rails 4.0 ships with "jQuery":http://jquery.com as the default JavaScript library. +The Gemfile contains +gem 'jquery-rails'+ which provides the +jquery.js+ and ++jquery_ujs.js+ files via the asset pipeline. + +You will have to use the +require+ directive to tell Sprockets to load +jquery.js+ +and +jquery.js+. For example, a new Rails application includes a default ++app/assets/javascripts/application.js+ file which contains the following lines: + +<plain> +// ... +//= require jquery +//= require jquery_ujs +// ... +</plain> + +The +application.js+ file acts like a manifest and is used to tell Sprockets the +files that you wish to require. In this case, you are requiring the files +jquery.js+ +and +jquery_ujs.js+ provided by the +jquery-rails+ gem. + +If the application is not using the asset pipeline, this can be accessed as: <ruby> javascript_include_tag :defaults </ruby> +By default, +:defaults+ loads jQuery. + +You can also choose to use Prototype instead of jQuery and specify the option +using +-j+ switch while generating the application. + +<shell> +rails new app_name -j prototype +</shell> + +This will add the +prototype-rails+ gem to the Gemfile and modify the ++app/assets/javascripts/application.js+ file: + +<plain> +// ... +//= require prototype +//= require prototype_ujs +// ... +</plain> + +You are ready to add some AJAX love to your Rails app! + h4. Examples -All the remote_method helpers has been removed. To make them working with AJAX, simply pass the <tt>:remote => true</tt> option to the original non-remote method. +To make them working with AJAX, simply pass the <tt>remote: true</tt> option to +the original non-remote method. <ruby> -button_to "New", :action => "new", :form_class => "new-thing" +button_to 'New', action: 'new', form_class: 'new-thing' </ruby> will produce @@ -49,7 +116,7 @@ will produce </html> <ruby> -button_to "Create", :action => "create", :remote => true, :form => { "data-type" => "json" } +button_to 'Create', action: 'create', remote: true, form: { 'data-type' => 'json' } </ruby> will produce @@ -61,8 +128,8 @@ will produce </html> <ruby> -button_to "Delete Image", { :action => "delete", :id => @image.id }, - :confirm => "Are you sure?", :method => :delete +button_to 'Delete Image', { action: 'delete', id: @image.id }, + method: :delete, data: { confirm: 'Are you sure?' } </ruby> will produce @@ -77,8 +144,8 @@ will produce </html> <ruby> -button_to('Destroy', 'http://www.example.com', :confirm => 'Are you sure?', - :method => "delete", :remote => true, 'data-disable-with' => 'loading...') +button_to 'Destroy', 'http://www.example.com', + method: 'delete', remote: true, data: { disable_with: 'loading...', confirm: 'Are you sure?' } </ruby> will produce @@ -92,14 +159,6 @@ will produce </form> </html> -You can also choose to use Prototype instead of jQuery and specify the option using +-j+ switch while generating the application. - -<shell> -rails new app_name -j prototype -</shell> - -You are ready to add some AJAX love to your Rails app! - h4. The Quintessential AJAX Rails Helper: link_to_remote Let's start with what is probably the most often used helper: +link_to_remote+. It has an interesting feature from the documentation point of view: the options supplied to +link_to_remote+ are shared by all other AJAX helpers, so learning the mechanics and options of +link_to_remote+ is a great help when using other helpers. @@ -158,7 +217,6 @@ link_to_remote "Delete the item", Note that if we wouldn't override the default behavior (POST), the above snippet would route to the create action rather than destroy. ** *JavaScript filters* You can customize the remote call further by wrapping it with some JavaScript code. Let's say in the previous example, when deleting a link, you'd like to ask for a confirmation by showing a simple modal text box to the user. This is a typical example what you can accomplish with these options - let's see them one by one: -*** +:confirm+ => +msg+ Pops up a JavaScript confirmation dialog, displaying +msg+. If the user chooses 'OK', the request is launched, otherwise canceled. *** +:condition+ => +code+ Evaluates +code+ (which should evaluate to a boolean) and proceeds if it's true, cancels the request otherwise. *** +:before+ => +code+ Evaluates the +code+ just before launching the request. The output of the code has no influence on the execution. Typically used show a progress indicator (see this in action in the next example). *** +:after+ => +code+ Evaluates the +code+ after launching the request. Note that this is different from the +:success+ or +:complete+ callback (covered in the next section) since those are triggered after the request is completed, while the code snippet passed to +:after+ is evaluated after the remote call is made. A common example is to disable elements on the page or otherwise prevent further action while the request is completed. @@ -223,23 +281,6 @@ h5. +form_remote_tag+ h5. +submit_to_remote+ -h4. Observing Elements - -h5. +observe_field+ - -h5. +observe_form+ - -h4. Calling a Function Periodically - -h5. +periodically_call_remote+ - - -h4. Miscellaneous Functionality - -h5. +remote_function+ - -h5. +update_page+ - h4. Serving JavaScript First we'll check out how to send JavaScript to the server manually. You are practically never going to need this, but it's interesting to understand what's going on under the hood. diff --git a/guides/source/api_documentation_guidelines.textile b/guides/source/api_documentation_guidelines.textile index c6aa1f0a2b..3de5b119ee 100644 --- a/guides/source/api_documentation_guidelines.textile +++ b/guides/source/api_documentation_guidelines.textile @@ -127,7 +127,7 @@ class Array end </ruby> -WARNING: Using a pair of ++...++ for fixed-width font only works with *words*; that is: anything matching <tt>\A\w+\z</tt>. For anything else use +<tt>...</tt>+, notably symbols, setters, inline snippets, etc: +WARNING: Using a pair of ++...++ for fixed-width font only works with *words*; that is: anything matching <tt>\A\w+\z</tt>. For anything else use +<tt>...</tt>+, notably symbols, setters, inline snippets, etc. h4. Regular Font diff --git a/guides/source/asset_pipeline.textile b/guides/source/asset_pipeline.textile index 105efe229e..e385ec4f17 100644 --- a/guides/source/asset_pipeline.textile +++ b/guides/source/asset_pipeline.textile @@ -121,7 +121,7 @@ h5. Search paths When a file is referenced from a manifest or a helper, Sprockets searches the three default asset locations for it. -The default locations are: +app/assets/images+ and the subdirectories +javascripts+ and +stylesheets+ in all three asset locations. +The default locations are: +app/assets/images+ and the subdirectories +javascripts+ and +stylesheets+ in all three asset locations, but these subdirectories are not special. Any path under +assets/*+ will be searched. For example, these files: @@ -129,6 +129,7 @@ For example, these files: app/assets/javascripts/home.js lib/assets/javascripts/moovinator.js vendor/assets/javascripts/slider.js +vendor/assets/somepackage/phonebox.js </plain> would be referenced in a manifest like this: @@ -137,6 +138,7 @@ would be referenced in a manifest like this: //= require home //= require moovinator //= require slider +//= require phonebox </plain> Assets inside subdirectories can also be accessed. @@ -153,13 +155,13 @@ is referenced as: You can view the search path by inspecting +Rails.application.config.assets.paths+ in the Rails console. -Additional (fully qualified) paths can be added to the pipeline in +config/application.rb+. For example: +Besides the standard +assets/*+ paths, additional (fully qualified) paths can be added to the pipeline in +config/application.rb+. For example: <ruby> -config.assets.paths << Rails.root.join("app", "assets", "flash") +config.assets.paths << Rails.root.join("lib", "videoplayer", "flash") </ruby> -Paths are traversed in the order that they occur in the search path. +Paths are traversed in the order that they occur in the search path. By default, this means the files in +app/assets+ take precedence, and will mask corresponding paths in +lib+ and +vendor+. It is important to note that files you want to reference outside a manifest must be added to the precompile array or they will not be available in the production environment. @@ -430,7 +432,7 @@ NOTE. If you are precompiling your assets locally, you can use +bundle install - The default matcher for compiling files includes +application.js+, +application.css+ and all non-JS/CSS files (this will include all image assets automatically): <ruby> -[ Proc.new{ |path| !File.extname(path).in?(['.js', '.css']) }, /application.(css|js)$/ ] +[ Proc.new{ |path| !%w(.js .css).include?(File.extname(path)) }, /application.(css|js)$/ ] </ruby> NOTE. The matcher (and other members of the precompile array; see below) is applied to final compiled file names. This means that anything that compiles to JS/CSS is excluded, as well as raw JS/CSS files; for example, +.coffee+ and +.scss+ files are *not* automatically included as they compile to JS/CSS. @@ -441,6 +443,8 @@ If you have other manifests or individual stylesheets and JavaScript files to in config.assets.precompile += ['admin.js', 'admin.css', 'swfObject.js'] </erb> +NOTE. Always specify an expected compiled filename that ends with js or css, even if you want to add Sass or CoffeeScript files to the precompile array. + The rake task also generates a +manifest.yml+ that contains a list with all your assets and their respective fingerprints. This is used by the Rails helper methods to avoid handing the mapping requests back to Sprockets. A typical manifest file looks like: <plain> @@ -649,11 +653,19 @@ Apache and nginx support this option, which can be enabled in <tt>config/environ WARNING: If you are upgrading an existing application and intend to use this option, take care to paste this configuration option only into +production.rb+ and any other environments you define with production behavior (not +application.rb+). -h3. How Caching Works +h3. Assets Cache Store + +The default Rails cache store will be used by Sprockets to cache assets in development and production. This can be changed by setting +config.assets.cache_store+. + +<ruby> +config.assets.cache_store = :memory_store +</ruby> -Sprockets uses the default Rails cache store to cache assets in development and production. +The options accepted by the assets cache store are the same as the application's cache store. -TODO: Add more about changing the default store. +<ruby> +config.assets.cache_store = :memory_store, { :size => 32.megabytes } +</ruby> h3. Adding Assets to Your Gems @@ -667,9 +679,11 @@ TODO: Registering gems on "Tilt":https://github.com/rtomayko/tilt enabling Sproc h3. Upgrading from Old Versions of Rails -There are two issues when upgrading. The first is moving the files from +public/+ to the new locations. See "Asset Organization":#asset-organization above for guidance on the correct locations for different file types. +There are a few issues when upgrading. The first is moving the files from +public/+ to the new locations. See "Asset Organization":#asset-organization above for guidance on the correct locations for different file types. + +Next will be avoiding duplicate JavaScript files. Since jQuery is the default JavaScript library from Rails 3.1 onwards, you don't need to copy +jquery.js+ into +app/assets+ and it will be included automatically. -The second is updating the various environment files with the correct default options. The following changes reflect the defaults in version 3.1.0. +The third is updating the various environment files with the correct default options. The following changes reflect the defaults in version 3.1.0. In +application.rb+: @@ -725,8 +739,8 @@ The following should also be added to +Gemfile+: # Gems used only for assets and not required # in production environments by default. group :assets do - gem 'sass-rails', "~> 3.1.0" - gem 'coffee-rails', "~> 3.1.0" + gem 'sass-rails', "~> 3.2.3" + gem 'coffee-rails', "~> 3.2.1" gem 'uglifier' end </plain> diff --git a/guides/source/association_basics.textile b/guides/source/association_basics.textile index 8ddc56bef1..d4c0a1ba74 100644 --- a/guides/source/association_basics.textile +++ b/guides/source/association_basics.textile @@ -630,12 +630,12 @@ The <tt>create_<em>association</em></tt> method returns a new object of the asso h5. Options for +belongs_to+ -While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the +belongs_to+ association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this assocation uses two such options: +While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the +belongs_to+ association reference. Such customizations can easily be accomplished by passing options and scope blocks when you create the association. For example, this assocation uses two such options: <ruby> class Order < ActiveRecord::Base - belongs_to :customer, :counter_cache => true, - :conditions => "active = 1" + belongs_to :customer, :dependent => :destroy, + :counter_cache => true end </ruby> @@ -643,15 +643,11 @@ The +belongs_to+ association supports these options: * +:autosave+ * +:class_name+ -* +:conditions+ * +:counter_cache+ * +:dependent+ * +:foreign_key+ -* +:include+ * +:inverse_of+ * +:polymorphic+ -* +:readonly+ -* +:select+ * +:touch+ * +:validate+ @@ -669,16 +665,6 @@ class Order < ActiveRecord::Base end </ruby> -h6(#belongs_to-conditions). +:conditions+ - -The +:conditions+ option lets you specify the conditions that the associated object must meet (in the syntax used by an SQL +WHERE+ clause). - -<ruby> -class Order < ActiveRecord::Base - belongs_to :customer, :conditions => "active = 1" -end -</ruby> - h6(#belongs_to-counter_cache). +:counter_cache+ The +:counter_cache+ option can be used to make finding the number of belonging objects more efficient. Consider these models: @@ -737,35 +723,31 @@ end TIP: In any case, Rails will not create foreign key columns for you. You need to explicitly define them as part of your migrations. -h6(#belongs_to-includes). +:include+ +h6(#belongs_to-inverse_of). +:inverse_of+ -You can use the +:include+ option to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models: +The +:inverse_of+ option specifies the name of the +has_many+ or +has_one+ association that is the inverse of this association. Does not work in combination with the +:polymorphic+ options. <ruby> -class LineItem < ActiveRecord::Base - belongs_to :order +class Customer < ActiveRecord::Base + has_many :orders, :inverse_of => :customer end class Order < ActiveRecord::Base - belongs_to :customer - has_many :line_items -end - -class Customer < ActiveRecord::Base - has_many :orders + belongs_to :customer, :inverse_of => :orders end </ruby> -If you frequently retrieve customers directly from line items (+@line_item.order.customer+), then you can make your code somewhat more efficient by including customers in the association from line items to orders: +h6(#belongs_to-polymorphic). +:polymorphic+ -<ruby> -class LineItem < ActiveRecord::Base - belongs_to :order, :include => :customer -end +Passing +true+ to the +:polymorphic+ option indicates that this is a polymorphic association. Polymorphic associations were discussed in detail <a href="#polymorphic-associations">earlier in this guide</a>. + +h6(#belongs_to-touch). +:touch+ + +If you set the +:touch+ option to +:true+, then the +updated_at+ or +updated_on+ timestamp on the associated object will be set to the current time whenever this object is saved or destroyed: +<ruby> class Order < ActiveRecord::Base - belongs_to :customer - has_many :line_items + belongs_to :customer, :touch => true end class Customer < ActiveRecord::Base @@ -773,43 +755,58 @@ class Customer < ActiveRecord::Base end </ruby> -NOTE: There's no need to use +:include+ for immediate associations - that is, if you have +Order belongs_to :customer+, then the customer is eager-loaded automatically when it's needed. - -h6(#belongs_to-inverse_of). +:inverse_of+ - -The +:inverse_of+ option specifies the name of the +has_many+ or +has_one+ association that is the inverse of this association. Does not work in combination with the +:polymorphic+ options. +In this case, saving or destroying an order will update the timestamp on the associated customer. You can also specify a particular timestamp attribute to update: <ruby> -class Customer < ActiveRecord::Base - has_many :orders, :inverse_of => :customer -end - class Order < ActiveRecord::Base - belongs_to :customer, :inverse_of => :orders + belongs_to :customer, :touch => :orders_updated_at end </ruby> -h6(#belongs_to-polymorphic). +:polymorphic+ +h6(#belongs_to-validate). +:validate+ -Passing +true+ to the +:polymorphic+ option indicates that this is a polymorphic association. Polymorphic associations were discussed in detail <a href="#polymorphic-associations">earlier in this guide</a>. +If you set the +:validate+ option to +true+, then associated objects will be validated whenever you save this object. By default, this is +false+: associated objects will not be validated when this object is saved. -h6(#belongs_to-readonly). +:readonly+ +h5(#belongs_to-scopes_for_belongs_to). Scopes for +belongs_to+ -If you set the +:readonly+ option to +true+, then the associated object will be read-only when retrieved via the association. +There may be times when you wish to customize the query used by +belongs_to+. Such customizations can be achieved via a scope block. For example: -h6(#belongs_to-select). +:select+ +<ruby> +class Order < ActiveRecord::Base + belongs_to :customer, -> { where :active => true }, + :dependent => :destroy +end +</ruby> -The +:select+ option lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated object. By default, Rails retrieves all columns. +You can use any of the standard "querying methods":active_record_querying.html inside the scope block. The following ones are discussed below: -TIP: If you set the +:select+ option on a +belongs_to+ association, you should also set the +foreign_key+ option to guarantee the correct results. +* +where+ +* +includes+ +* +readonly+ +* +select+ -h6(#belongs_to-touch). +:touch+ +h6(#belongs_to-where). +where+ -If you set the +:touch+ option to +:true+, then the +updated_at+ or +updated_on+ timestamp on the associated object will be set to the current time whenever this object is saved or destroyed: +The +where+ method lets you specify the conditions that the associated object must meet. <ruby> class Order < ActiveRecord::Base - belongs_to :customer, :touch => true + belongs_to :customer, -> { where :active => true } +end +</ruby> + +h6(#belongs_to-includes). +includes+ + +You can use the +includes+ method let you specify second-order associations that should be eager-loaded when this association is used. For example, consider these models: + +<ruby> +class LineItem < ActiveRecord::Base + belongs_to :order +end + +class Order < ActiveRecord::Base + belongs_to :customer + has_many :line_items end class Customer < ActiveRecord::Base @@ -817,17 +814,34 @@ class Customer < ActiveRecord::Base end </ruby> -In this case, saving or destroying an order will update the timestamp on the associated customer. You can also specify a particular timestamp attribute to update: +If you frequently retrieve customers directly from line items (+@line_item.order.customer+), then you can make your code somewhat more efficient by including customers in the association from line items to orders: <ruby> +class LineItem < ActiveRecord::Base + belongs_to :order, -> { includes :customer } +end + class Order < ActiveRecord::Base - belongs_to :customer, :touch => :orders_updated_at + belongs_to :customer + has_many :line_items +end + +class Customer < ActiveRecord::Base + has_many :orders end </ruby> -h6(#belongs_to-validate). +:validate+ +NOTE: There's no need to use +includes+ for immediate associations - that is, if you have +Order belongs_to :customer+, then the customer is eager-loaded automatically when it's needed. -If you set the +:validate+ option to +true+, then associated objects will be validated whenever you save this object. By default, this is +false+: associated objects will not be validated when this object is saved. +h6(#belongs_to-readonly). +readonly+ + +If you use +readonly+, then the associated object will be read-only when retrieved via the association. + +h6(#belongs_to-select). +select+ + +The +select+ method lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated object. By default, Rails retrieves all columns. + +TIP: If you use the +select+ method on a +belongs_to+ association, you should also set the +:foreign_key+ option to guarantee the correct results. h5(#belongs_to-do_any_associated_objects_exist). Do Any Associated Objects Exist? @@ -924,15 +938,10 @@ The +has_one+ association supports these options: * +:as+ * +:autosave+ * +:class_name+ -* +:conditions+ * +:dependent+ * +:foreign_key+ -* +:include+ * +:inverse_of+ -* +:order+ * +:primary_key+ -* +:readonly+ -* +:select+ * +:source+ * +:source_type+ * +:through+ @@ -956,22 +965,15 @@ class Supplier < ActiveRecord::Base end </ruby> -h6(#has_one-conditions). +:conditions+ - -The +:conditions+ option lets you specify the conditions that the associated object must meet (in the syntax used by an SQL +WHERE+ clause). - -<ruby> -class Supplier < ActiveRecord::Base - has_one :account, :conditions => "confirmed = 1" -end -</ruby> - h6(#has_one-dependent). +:dependent+ -If you set the +:dependent+ option to +:destroy+, then deleting this object will call the +destroy+ method on the associated object to delete that object. If you set the +:dependent+ option to +:delete+, then deleting this object will delete the associated object _without_ calling its +destroy+ method. If you set the +:dependent+ option to +:nullify+, then deleting this object will set the foreign key in the association object to +NULL+. -If you set the +:dependent+ option to +:restrict+, then the deletion of the object is restricted if a dependent associated object exist and a +DeleteRestrictionError+ exception is raised. +Controls what happens to the associated object when its owner is destroyed: -NOTE: The default behavior for +:dependent => :restrict+ is to raise a +DeleteRestrictionError+ when associated objects exist. Since Rails 4.0 this behavior is being deprecated in favor of adding an error to the base model. To silence the warning in Rails 4.0, you should fix your code to not expect this Exception and add +config.active_record.dependent_restrict_raises = false+ to your application config. +* +:destroy+ causes the associated object to also be destroyed +* +:delete+ causes the asssociated object to be deleted directly from the database (so callbacks will not execute) +* +:nullify+ causes the foreign key to be set to +NULL+. Callbacks are not executed. +* +:restrict_with_exception+ causes an exception to be raised if there is an associated record +* +:restrict_with_error+ causes an error to be added to the owner if there is an associated object h6(#has_one-foreign_key). +:foreign_key+ @@ -985,30 +987,74 @@ end TIP: In any case, Rails will not create foreign key columns for you. You need to explicitly define them as part of your migrations. -h6(#has_one-include). +:include+ +h6(#has_one-inverse_of). +:inverse_of+ -You can use the +:include+ option to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models: +The +:inverse_of+ option specifies the name of the +belongs_to+ association that is the inverse of this association. Does not work in combination with the +:through+ or +:as+ options. <ruby> class Supplier < ActiveRecord::Base - has_one :account + has_one :account, :inverse_of => :supplier end class Account < ActiveRecord::Base - belongs_to :supplier - belongs_to :representative + belongs_to :supplier, :inverse_of => :account end +</ruby> -class Representative < ActiveRecord::Base - has_many :accounts +h6(#has_one-primary_key). +:primary_key+ + +By convention, Rails assumes that the column used to hold the primary key of this model is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. + +h6(#has_one-source). +:source+ + +The +:source+ option specifies the source association name for a +has_one :through+ association. + +h6(#has_one-source_type). +:source_type+ + +The +:source_type+ option specifies the source association type for a +has_one :through+ association that proceeds through a polymorphic association. + +h6(#has_one-through). +:through+ + +The +:through+ option specifies a join model through which to perform the query. +has_one :through+ associations were discussed in detail <a href="#the-has_one-through-association">earlier in this guide</a>. + +h6(#has_one-validate). +:validate+ + +If you set the +:validate+ option to +true+, then associated objects will be validated whenever you save this object. By default, this is +false+: associated objects will not be validated when this object is saved. + +h5(#belongs_to-scopes_for_has_one). Scopes for +has_one+ + +There may be times when you wish to customize the query used by +has_one+. Such customizations can be achieved via a scope block. For example: + +<ruby> +class Supplier < ActiveRecord::Base + has_one :account, -> { where :active => true } end </ruby> -If you frequently retrieve representatives directly from suppliers (+@supplier.account.representative+), then you can make your code somewhat more efficient by including representatives in the association from suppliers to accounts: +You can use any of the standard "querying methods":active_record_querying.html inside the scope block. The following ones are discussed below: + +* +where+ +* +includes+ +* +readonly+ +* +select+ + +h6(#has_one-where). +where+ + +The +where+ method lets you specify the conditions that the associated object must meet. + +<ruby> +class Supplier < ActiveRecord::Base + has_one :account, -> { where "confirmed = 1" } +end +</ruby> + +h6(#has_one-includes). +includes+ + +You can use the +includes+ method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models: <ruby> class Supplier < ActiveRecord::Base - has_one :account, :include => :representative + has_one :account end class Account < ActiveRecord::Base @@ -1021,51 +1067,30 @@ class Representative < ActiveRecord::Base end </ruby> -h6(#has_one-inverse_of). +:inverse_of+ - -The +:inverse_of+ option specifies the name of the +belongs_to+ association that is the inverse of this association. Does not work in combination with the +:through+ or +:as+ options. +If you frequently retrieve representatives directly from suppliers (+@supplier.account.representative+), then you can make your code somewhat more efficient by including representatives in the association from suppliers to accounts: <ruby> class Supplier < ActiveRecord::Base - has_one :account, :inverse_of => :supplier + has_one :account, -> { includes :representative } end class Account < ActiveRecord::Base - belongs_to :supplier, :inverse_of => :account + belongs_to :supplier + belongs_to :representative end -</ruby> - -h6(#has_one-order). +:order+ -The +:order+ option dictates the order in which associated objects will be received (in the syntax used by an SQL +ORDER BY+ clause). Because a +has_one+ association will only retrieve a single associated object, this option should not be needed. - -h6(#has_one-primary_key). +:primary_key+ - -By convention, Rails assumes that the column used to hold the primary key of this model is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. - -h6(#has_one-readonly). +:readonly+ - -If you set the +:readonly+ option to +true+, then the associated object will be read-only when retrieved via the association. - -h6(#has_one-select). +:select+ - -The +:select+ option lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated object. By default, Rails retrieves all columns. - -h6(#has_one-source). +:source+ - -The +:source+ option specifies the source association name for a +has_one :through+ association. - -h6(#has_one-source_type). +:source_type+ - -The +:source_type+ option specifies the source association type for a +has_one :through+ association that proceeds through a polymorphic association. +class Representative < ActiveRecord::Base + has_many :accounts +end +</ruby> -h6(#has_one-through). +:through+ +h6(#has_one-readonly). +readonly+ -The +:through+ option specifies a join model through which to perform the query. +has_one :through+ associations were discussed in detail <a href="#the-has_one-through-association">earlier in this guide</a>. +If you use the +readonly+ method, then the associated object will be read-only when retrieved via the association. -h6(#has_one-validate). +:validate+ +h6(#has_one-select). +select+ -If you set the +:validate+ option to +true+, then associated objects will be validated whenever you save this object. By default, this is +false+: associated objects will not be validated when this object is saved. +The +select+ method lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated object. By default, Rails retrieves all columns. h5(#has_one-do_any_associated_objects_exist). Do Any Associated Objects Exist? @@ -1256,25 +1281,13 @@ The +has_many+ association supports these options: * +:as+ * +:autosave+ * +:class_name+ -* +:conditions+ -* +:counter_sql+ * +:dependent+ -* +:extend+ -* +:finder_sql+ * +:foreign_key+ -* +:group+ -* +:include+ * +:inverse_of+ -* +:limit+ -* +:offset+ -* +:order+ * +:primary_key+ -* +:readonly+ -* +:select+ * +:source+ * +:source_type+ * +:through+ -* +:uniq+ * +:validate+ h6(#has_many-as). +:as+ @@ -1295,85 +1308,127 @@ class Customer < ActiveRecord::Base end </ruby> -h6(#has_many-conditions). +:conditions+ +h6(#has_many-dependent). +:dependent+ -The +:conditions+ option lets you specify the conditions that the associated object must meet (in the syntax used by an SQL +WHERE+ clause). +Controls what happens to the associated objects when their owner is destroyed: -<ruby> -class Customer < ActiveRecord::Base - has_many :confirmed_orders, :class_name => "Order", - :conditions => "confirmed = 1" -end -</ruby> +* +:destroy+ causes all the associated objects to also be destroyed +* +:delete_all+ causes all the asssociated objects to be deleted directly from the database (so callbacks will not execute) +* +:nullify+ causes the foreign keys to be set to +NULL+. Callbacks are not executed. +* +:restrict_with_exception+ causes an exception to be raised if there are any associated records +* +:restrict_with_error+ causes an error to be added to the owner if there are any associated objects -You can also set conditions via a hash: +NOTE: This option is ignored when you use the +:through+ option on the association. + +h6(#has_many-foreign_key). +:foreign_key+ + +By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: <ruby> class Customer < ActiveRecord::Base - has_many :confirmed_orders, :class_name => "Order", - :conditions => { :confirmed => true } + has_many :orders, :foreign_key => "cust_id" end </ruby> -If you use a hash-style +:conditions+ option, then record creation via this association will be automatically scoped using the hash. In this case, using +@customer.confirmed_orders.create+ or +@customer.confirmed_orders.build+ will create orders where the confirmed column has the value +true+. +TIP: In any case, Rails will not create foreign key columns for you. You need to explicitly define them as part of your migrations. -If you need to evaluate conditions dynamically at runtime, use a proc: +h6(#has_many-inverse_of). +:inverse_of+ + +The +:inverse_of+ option specifies the name of the +belongs_to+ association that is the inverse of this association. Does not work in combination with the +:through+ or +:as+ options. <ruby> class Customer < ActiveRecord::Base - has_many :latest_orders, :class_name => "Order", - :conditions => proc { ["orders.created_at > ?", 10.hours.ago] } + has_many :orders, :inverse_of => :customer +end + +class Order < ActiveRecord::Base + belongs_to :customer, :inverse_of => :orders end </ruby> -h6(#has_many-counter_sql). +:counter_sql+ +h6(#has_many-primary_key). +:primary_key+ -Normally Rails automatically generates the proper SQL to count the association members. With the +:counter_sql+ option, you can specify a complete SQL statement to count them yourself. +By convention, Rails assumes that the column used to hold the primary key of the association is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. -NOTE: If you specify +:finder_sql+ but not +:counter_sql+, then the counter SQL will be generated by substituting the +SELECT ... FROM+ clause of your +:finder_sql+ statement by +SELECT COUNT(*) FROM+. +h6(#has_many-source). +:source+ -h6(#has_many-dependent). +:dependent+ +The +:source+ option specifies the source association name for a +has_many :through+ association. You only need to use this option if the name of the source association cannot be automatically inferred from the association name. -If you set the +:dependent+ option to +:destroy+, then deleting this object will call the +destroy+ method on the associated objects to delete those objects. If you set the +:dependent+ option to +:delete_all+, then deleting this object will delete the associated objects _without_ calling their +destroy+ method. If you set the +:dependent+ option to +:nullify+, then deleting this object will set the foreign key in the associated objects to +NULL+. -If you set the +:dependent+ option to +:restrict+, then the deletion of the object is restricted if a dependent associated object exist and a +DeleteRestrictionError+ exception is raised. +h6(#has_many-source_type). +:source_type+ -NOTE: The default behavior for +:dependent => :restrict+ is to raise a +DeleteRestrictionError+ when associated objects exist. Since Rails 4.0 this behavior is being deprecated in favor of adding an error to the base model. To silence the warning in Rails 4.0, you should fix your code to not expect this Exception and add +config.active_record.dependent_restrict_raises = false+ to your application config. +The +:source_type+ option specifies the source association type for a +has_many :through+ association that proceeds through a polymorphic association. -NOTE: This option is ignored when you use the +:through+ option on the association. +h6(#has_many-through). +:through+ -h6(#has_many-extend). +:extend+ +The +:through+ option specifies a join model through which to perform the query. +has_many :through+ associations provide a way to implement many-to-many relationships, as discussed <a href="#the-has_many-through-association">earlier in this guide</a>. -The +:extend+ option specifies a named module to extend the association proxy. Association extensions are discussed in detail <a href="#association-extensions">later in this guide</a>. +h6(#has_many-validate). +:validate+ -h6(#has_many-finder_sql). +:finder_sql+ +If you set the +:validate+ option to +false+, then associated objects will not be validated whenever you save this object. By default, this is +true+: associated objects will be validated when this object is saved. -Normally Rails automatically generates the proper SQL to fetch the association members. With the +:finder_sql+ option, you can specify a complete SQL statement to fetch them yourself. If fetching objects requires complex multi-table SQL, this may be necessary. +h5(#has_many-scopes_for_has_many). Scopes for +has_many+ -h6(#has_many-foreign_key). +:foreign_key+ +There may be times when you wish to customize the query used by +has_many+. Such customizations can be achieved via a scope block. For example: -By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: +<ruby> +class Customer < ActiveRecord::Base + has_many :orders, -> { where :processed => true } +end +</ruby> + +You can use any of the standard "querying methods":active_record_querying.html inside the scope block. The following ones are discussed below: + +* +where+ +* +extending+ +* +group+ +* +includes+ +* +limit+ +* +offset+ +* +order+ +* +readonly+ +* +select+ +* +uniq+ + +h6(#has_many-where). +where+ + +The +where+ method lets you specify the conditions that the associated object must meet. <ruby> class Customer < ActiveRecord::Base - has_many :orders, :foreign_key => "cust_id" + has_many :confirmed_orders, -> { where "confirmed = 1" }, + :class_name => "Order" end </ruby> -TIP: In any case, Rails will not create foreign key columns for you. You need to explicitly define them as part of your migrations. +You can also set conditions via a hash: -h6(#has_many-group). +:group+ +<ruby> +class Customer < ActiveRecord::Base + has_many :confirmed_orders, -> { where :confirmed => true }, + :class_name => "Order" +end +</ruby> + +If you use a hash-style +where+ option, then record creation via this association will be automatically scoped using the hash. In this case, using +@customer.confirmed_orders.create+ or +@customer.confirmed_orders.build+ will create orders where the confirmed column has the value +true+. -The +:group+ option supplies an attribute name to group the result set by, using a +GROUP BY+ clause in the finder SQL. +h6(#has_many-extending). +extending+ + +The +extending+ method specifies a named module to extend the association proxy. Association extensions are discussed in detail <a href="#association-extensions">later in this guide</a>. + +h6(#has_many-group). +group+ + +The +group+ method supplies an attribute name to group the result set by, using a +GROUP BY+ clause in the finder SQL. <ruby> class Customer < ActiveRecord::Base - has_many :line_items, :through => :orders, :group => "orders.id" + has_many :line_items, -> { group 'orders.id' }, + :through => :orders end </ruby> -h6(#has_many-include). +:include+ +h6(#has_many-includes). +includes+ -You can use the +:include+ option to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models: +You can use the +includes+ method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models: <ruby> class Customer < ActiveRecord::Base @@ -1394,7 +1449,7 @@ If you frequently retrieve line items directly from customers (+@customer.orders <ruby> class Customer < ActiveRecord::Base - has_many :orders, :include => :line_items + has_many :orders, -> { includes :line_items } end class Order < ActiveRecord::Base @@ -1407,74 +1462,45 @@ class LineItem < ActiveRecord::Base end </ruby> -h6(#has_many-inverse_of). +:inverse_of+ +h6(#has_many-limit). +limit+ -The +:inverse_of+ option specifies the name of the +belongs_to+ association that is the inverse of this association. Does not work in combination with the +:through+ or +:as+ options. +The +limit+ method lets you restrict the total number of objects that will be fetched through an association. <ruby> class Customer < ActiveRecord::Base - has_many :orders, :inverse_of => :customer -end - -class Order < ActiveRecord::Base - belongs_to :customer, :inverse_of => :orders + has_many :recent_orders, + -> { order('order_date desc').limit(100) }, + :class_name => "Order", end </ruby> -h6(#has_many-limit). +:limit+ +h6(#has_many-offset). +offset+ -The +:limit+ option lets you restrict the total number of objects that will be fetched through an association. - -<ruby> -class Customer < ActiveRecord::Base - has_many :recent_orders, :class_name => "Order", - :order => "order_date DESC", :limit => 100 -end -</ruby> +The +offset+ method lets you specify the starting offset for fetching objects via an association. For example, +-> { offset(11) }+ will skip the first 11 records. -h6(#has_many-offset). +:offset+ +h6(#has_many-order). +order+ -The +:offset+ option lets you specify the starting offset for fetching objects via an association. For example, if you set +:offset => 11+, it will skip the first 11 records. - -h6(#has_many-order). +:order+ - -The +:order+ option dictates the order in which associated objects will be received (in the syntax used by an SQL +ORDER BY+ clause). +The +order+ method dictates the order in which associated objects will be received (in the syntax used by an SQL +ORDER BY+ clause). <ruby> class Customer < ActiveRecord::Base - has_many :orders, :order => "date_confirmed DESC" + has_many :orders, -> { order "date_confirmed DESC" } end </ruby> -h6(#has_many-primary_key). +:primary_key+ - -By convention, Rails assumes that the column used to hold the primary key of the association is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. - -h6(#has_many-readonly). +:readonly+ - -If you set the +:readonly+ option to +true+, then the associated objects will be read-only when retrieved via the association. - -h6(#has_many-select). +:select+ - -The +:select+ option lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated objects. By default, Rails retrieves all columns. - -WARNING: If you specify your own +:select+, be sure to include the primary key and foreign key columns of the associated model. If you do not, Rails will throw an error. +h6(#has_many-readonly). +readonly+ -h6(#has_many-source). +:source+ - -The +:source+ option specifies the source association name for a +has_many :through+ association. You only need to use this option if the name of the source association cannot be automatically inferred from the association name. - -h6(#has_many-source_type). +:source_type+ +If you use the +readonly+ method, then the associated objects will be read-only when retrieved via the association. -The +:source_type+ option specifies the source association type for a +has_many :through+ association that proceeds through a polymorphic association. +h6(#has_many-select). +select+ -h6(#has_many-through). +:through+ +The +select+ method lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated objects. By default, Rails retrieves all columns. -The +:through+ option specifies a join model through which to perform the query. +has_many :through+ associations provide a way to implement many-to-many relationships, as discussed <a href="#the-has_many-through-association">earlier in this guide</a>. +WARNING: If you specify your own +select+, be sure to include the primary key and foreign key columns of the associated model. If you do not, Rails will throw an error. -h6(#has_many-uniq). +:uniq+ +h6(#has_many-uniq). +uniq+ -Set the +:uniq+ option to true to keep the collection free of duplicates. This is mostly useful together with the +:through+ option. +Use the +uniq+ method to keep the collection free of duplicates. This is mostly useful together with the +:through+ option. <ruby> class Person < ActiveRecord::Base @@ -1492,12 +1518,12 @@ Reading.all.inspect # => [#<Reading id: 12, person_id: 5, post_id: 5>, #<Readin In the above case there are two readings and +person.posts+ brings out both of them even though these records are pointing to the same post. -Now let's set +:uniq+ to true: +Now let's set +uniq+: <ruby> class Person has_many :readings - has_many :posts, :through => :readings, :uniq => true + has_many :posts, -> { uniq }, :through => :readings end person = Person.create(:name => 'honda') @@ -1510,10 +1536,6 @@ Reading.all.inspect # => [#<Reading id: 16, person_id: 7, post_id: 7>, #<Readin In the above case there are still two readings. However +person.posts+ shows only one post because the collection loads only unique records. -h6(#has_many-validate). +:validate+ - -If you set the +:validate+ option to +false+, then associated objects will not be validated whenever you save this object. By default, this is +true+: associated objects will be validated when this object is saved. - h5(#has_many-when_are_objects_saved). When are Objects Saved? When you assign an object to a +has_many+ association, that object is automatically saved (in order to update its foreign key). If you assign multiple objects in one statement, then they are all saved. @@ -1699,22 +1721,8 @@ The +has_and_belongs_to_many+ association supports these options: * +:association_foreign_key+ * +:autosave+ * +:class_name+ -* +:conditions+ -* +:counter_sql+ -* +:delete_sql+ -* +:extend+ -* +:finder_sql+ * +:foreign_key+ -* +:group+ -* +:include+ -* +:insert_sql+ * +:join_table+ -* +:limit+ -* +:offset+ -* +:order+ -* +:readonly+ -* +:select+ -* +:uniq+ * +:validate+ h6(#has_and_belongs_to_many-association_foreign_key). +:association_foreign_key+ @@ -1745,120 +1753,126 @@ class Parts < ActiveRecord::Base end </ruby> -h6(#has_and_belongs_to_many-conditions). +:conditions+ - -The +:conditions+ option lets you specify the conditions that the associated object must meet (in the syntax used by an SQL +WHERE+ clause). - -<ruby> -class Parts < ActiveRecord::Base - has_and_belongs_to_many :assemblies, - :conditions => "factory = 'Seattle'" -end -</ruby> +h6(#has_and_belongs_to_many-foreign_key). +:foreign_key+ -You can also set conditions via a hash: +By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: <ruby> -class Parts < ActiveRecord::Base - has_and_belongs_to_many :assemblies, - :conditions => { :factory => 'Seattle' } +class User < ActiveRecord::Base + has_and_belongs_to_many :friends, :class_name => "User", + :foreign_key => "this_user_id", + :association_foreign_key => "other_user_id" end </ruby> -If you use a hash-style +:conditions+ option, then record creation via this association will be automatically scoped using the hash. In this case, using +@parts.assemblies.create+ or +@parts.assemblies.build+ will create orders where the +factory+ column has the value "Seattle". - -h6(#has_and_belongs_to_many-counter_sql). +:counter_sql+ +h6(#has_and_belongs_to_many-join_table). +:join_table+ -Normally Rails automatically generates the proper SQL to count the association members. With the +:counter_sql+ option, you can specify a complete SQL statement to count them yourself. +If the default name of the join table, based on lexical ordering, is not what you want, you can use the +:join_table+ option to override the default. -NOTE: If you specify +:finder_sql+ but not +:counter_sql+, then the counter SQL will be generated by substituting the +SELECT ... FROM+ clause of your +:finder_sql+ statement by +SELECT COUNT(*) FROM+. +h6(#has_and_belongs_to_many-validate). +:validate+ -h6(#has_and_belongs_to_many-delete_sql). +:delete_sql+ +If you set the +:validate+ option to +false+, then associated objects will not be validated whenever you save this object. By default, this is +true+: associated objects will be validated when this object is saved. -Normally Rails automatically generates the proper SQL to remove links between the associated classes. With the +:delete_sql+ option, you can specify a complete SQL statement to delete them yourself. +h5(#has_and_belongs_to_many-scopes_for_has_and_belongs_to_many). Scopes for +has_and_belongs_to_many+ -h6(#has_and_belongs_to_many-extend). +:extend+ +There may be times when you wish to customize the query used by +has_and_belongs_to_many+. Such customizations can be achieved via a scope block. For example: -The +:extend+ option specifies a named module to extend the association proxy. Association extensions are discussed in detail <a href="#association-extensions">later in this guide</a>. +<ruby> +class Parts < ActiveRecord::Base + has_and_belongs_to_many :assemblies, -> { where :active => true } +end +</ruby> -h6(#has_and_belongs_to_many-finder_sql). +:finder_sql+ +You can use any of the standard "querying methods":active_record_querying.html inside the scope block. The following ones are discussed below: -Normally Rails automatically generates the proper SQL to fetch the association members. With the +:finder_sql+ option, you can specify a complete SQL statement to fetch them yourself. If fetching objects requires complex multi-table SQL, this may be necessary. +* +where+ +* +extending+ +* +group+ +* +includes+ +* +limit+ +* +offset+ +* +order+ +* +readonly+ +* +select+ +* +uniq+ -h6(#has_and_belongs_to_many-foreign_key). +:foreign_key+ +h6(#has_and_belongs_to_many-where). +where+ -By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: +The +where+ method lets you specify the conditions that the associated object must meet. <ruby> -class User < ActiveRecord::Base - has_and_belongs_to_many :friends, :class_name => "User", - :foreign_key => "this_user_id", - :association_foreign_key => "other_user_id" +class Parts < ActiveRecord::Base + has_and_belongs_to_many :assemblies, + -> { where "factory = 'Seattle'" } end </ruby> -h6(#has_and_belongs_to_many-group). +:group+ - -The +:group+ option supplies an attribute name to group the result set by, using a +GROUP BY+ clause in the finder SQL. +You can also set conditions via a hash: <ruby> class Parts < ActiveRecord::Base - has_and_belongs_to_many :assemblies, :group => "factory" + has_and_belongs_to_many :assemblies, + -> { where :factory => 'Seattle' } end </ruby> -h6(#has_and_belongs_to_many-include). +:include+ +If you use a hash-style +where+, then record creation via this association will be automatically scoped using the hash. In this case, using +@parts.assemblies.create+ or +@parts.assemblies.build+ will create orders where the +factory+ column has the value "Seattle". -You can use the +:include+ option to specify second-order associations that should be eager-loaded when this association is used. +h6(#has_and_belongs_to_many-extending). +extending+ -h6(#has_and_belongs_to_many-insert_sql). +:insert_sql+ +The +extending+ method specifies a named module to extend the association proxy. Association extensions are discussed in detail <a href="#association-extensions">later in this guide</a>. -Normally Rails automatically generates the proper SQL to create links between the associated classes. With the +:insert_sql+ option, you can specify a complete SQL statement to insert them yourself. +h6(#has_and_belongs_to_many-group). +group+ -h6(#has_and_belongs_to_many-join_table). +:join_table+ +The +group+ method supplies an attribute name to group the result set by, using a +GROUP BY+ clause in the finder SQL. -If the default name of the join table, based on lexical ordering, is not what you want, you can use the +:join_table+ option to override the default. +<ruby> +class Parts < ActiveRecord::Base + has_and_belongs_to_many :assemblies, -> { group "factory" } +end +</ruby> + +h6(#has_and_belongs_to_many-includes). +includes+ -h6(#has_and_belongs_to_many-limit). +:limit+ +You can use the +includes+ method to specify second-order associations that should be eager-loaded when this association is used. -The +:limit+ option lets you restrict the total number of objects that will be fetched through an association. +h6(#has_and_belongs_to_many-limit). +limit+ + +The +limit+ method lets you restrict the total number of objects that will be fetched through an association. <ruby> class Parts < ActiveRecord::Base - has_and_belongs_to_many :assemblies, :order => "created_at DESC", - :limit => 50 + has_and_belongs_to_many :assemblies, + -> { order("created_at DESC").limit(50) } end </ruby> -h6(#has_and_belongs_to_many-offset). +:offset+ +h6(#has_and_belongs_to_many-offset). +offset+ -The +:offset+ option lets you specify the starting offset for fetching objects via an association. For example, if you set +:offset => 11+, it will skip the first 11 records. +The +offset+ method lets you specify the starting offset for fetching objects via an association. For example, if you set +offset(11)+, it will skip the first 11 records. -h6(#has_and_belongs_to_many-order). +:order+ +h6(#has_and_belongs_to_many-order). +order+ -The +:order+ option dictates the order in which associated objects will be received (in the syntax used by an SQL +ORDER BY+ clause). +The +order+ method dictates the order in which associated objects will be received (in the syntax used by an SQL +ORDER BY+ clause). <ruby> class Parts < ActiveRecord::Base - has_and_belongs_to_many :assemblies, :order => "assembly_name ASC" + has_and_belongs_to_many :assemblies, + -> { order "assembly_name ASC" } end </ruby> -h6(#has_and_belongs_to_many-readonly). +:readonly+ +h6(#has_and_belongs_to_many-readonly). +readonly+ -If you set the +:readonly+ option to +true+, then the associated objects will be read-only when retrieved via the association. +If you use the +readonly+ method, then the associated objects will be read-only when retrieved via the association. -h6(#has_and_belongs_to_many-select). +:select+ +h6(#has_and_belongs_to_many-select). +select+ -The +:select+ option lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated objects. By default, Rails retrieves all columns. +The +select+ method lets you override the SQL +SELECT+ clause that is used to retrieve data about the associated objects. By default, Rails retrieves all columns. -h6(#has_and_belongs_to_many-uniq). +:uniq+ +h6(#has_and_belongs_to_many-uniq). +uniq+ -Specify the +:uniq => true+ option to remove duplicates from the collection. - -h6(#has_and_belongs_to_many-validate). +:validate+ - -If you set the +:validate+ option to +false+, then associated objects will not be validated whenever you save this object. By default, this is +true+: associated objects will be validated when this object is saved. +Use the +uniq+ method to remove duplicates from the collection. h5(#has_and_belongs_to_many-when_are_objects_saved). When are Objects Saved? @@ -1938,20 +1952,11 @@ module FindRecentExtension end class Customer < ActiveRecord::Base - has_many :orders, :extend => FindRecentExtension + has_many :orders, -> { extending FindRecentExtension } end class Supplier < ActiveRecord::Base - has_many :deliveries, :extend => FindRecentExtension -end -</ruby> - -To include more than one extension module in a single association, specify an array of modules: - -<ruby> -class Customer < ActiveRecord::Base - has_many :orders, - :extend => [FindRecentExtension, FindActiveExtension] + has_many :deliveries, -> { extending FindRecentExtension } end </ruby> diff --git a/guides/source/caching_with_rails.textile b/guides/source/caching_with_rails.textile index 34a100cd3a..815b2ef9c2 100644 --- a/guides/source/caching_with_rails.textile +++ b/guides/source/caching_with_rails.textile @@ -33,7 +33,7 @@ class ProductsController < ActionController caches_page :index def index - @products = Products.all + @products = Product.all end end </ruby> @@ -52,7 +52,7 @@ class ProductsController < ActionController caches_page :index def index - @products = Products.all + @products = Product.all end def create @@ -332,7 +332,7 @@ h4. ActiveSupport::Cache::MemoryStore This cache store keeps entries in memory in the same Ruby process. The cache store has a bounded size specified by the +:size+ options to the initializer (default is 32Mb). When the cache exceeds the allotted size, a cleanup will occur and the least recently used entries will be removed. <ruby> -config.cache_store = :memory_store, :size => 64.megabytes +config.cache_store = :memory_store, { :size => 64.megabytes } </ruby> If you're running multiple Ruby on Rails server processes (which is the case if you're using mongrel_cluster or Phusion Passenger), then your Rails server process instances won't be able to share cache data with each other. This cache store is not appropriate for large application deployments, but can work well for small, low traffic sites with only a couple of server processes or for development and test environments. diff --git a/guides/source/command_line.textile b/guides/source/command_line.textile index 19e42cea93..39b75c2781 100644 --- a/guides/source/command_line.textile +++ b/guides/source/command_line.textile @@ -160,7 +160,7 @@ $ rails generate controller Greetings hello create app/assets/stylesheets/greetings.css.scss </shell> -What all did this generate? It made sure a bunch of directories were in our application, and created a controller file, a view file, a functional test file, a helper for the view, a javascript file and a stylesheet file. +What all did this generate? It made sure a bunch of directories were in our application, and created a controller file, a view file, a functional test file, a helper for the view, a JavaScript file and a stylesheet file. Check out the controller and modify it a little (in +app/controllers/greetings_controller.rb+): @@ -477,6 +477,53 @@ h4. Miscellaneous * +rake secret+ will give you a pseudo-random key to use for your session secret. * <tt>rake time:zones:all</tt> lists all the timezones Rails knows about. +h4. Writing Rake Tasks + +If you have (or want to write) any automation scripts outside your app (data import, checks, etc), you can make them as rake tasks. It's easy. + +INFO: "Complete guide about how to write tasks":http://rake.rubyforge.org/files/doc/rakefile_rdoc.html is available in the official documentation. + +Tasks should be placed in <tt>Rails.root/lib/tasks</tt> and should have a +.rake+ extension. + +Each task should be defined in next format (dependencies are optional): + +<ruby> +desc "I am short, but comprehensive description for my cool task" +task :task_name => [:prerequisite_task, :another_task_we_depend_on] do + # All your magick here + # Any valid Ruby code is allowed +end +</ruby> + +If you need to pass parameters, you can use next format (both arguments and dependencies are optional): + +<ruby> +task :task_name, [:arg_1] => [:pre_1, :pre_2] do |t, args| + # You can use args from here +end +</ruby> + +You can group tasks by placing them in namespaces: + +<ruby> +namespace :do + desc "This task does nothing" + task :nothing do + # Seriously, nothing + end +end +</ruby> + +You can see your tasks to be listed by <tt>rake -T</tt> command. And, according to the examples above, you can invoke them as follows: + +<shell> +rake task_name +rake "task_name[value 1]" # entire argument string should be quoted +rake do:nothing +</shell> + +NOTE: If your need to interact with your application models, perform database queries and so on, your task should depend on the +environment+ task, which will load your application code. + h3. The Rails Advanced Command Line More advanced use of the command line is focused around finding useful (even surprising at times) options in the utilities, and fitting those to your needs and specific work flow. Listed here are some tricks up Rails' sleeve. diff --git a/guides/source/configuring.textile b/guides/source/configuring.textile index af46538bf5..27eaf1cbc5 100644 --- a/guides/source/configuring.textile +++ b/guides/source/configuring.textile @@ -50,8 +50,6 @@ config.after_initialize do end </ruby> -* +config.allow_concurrency+ should be true to allow concurrent (threadsafe) action processing. False by default. You probably don't want to call this one directly, though, because a series of other adjustments need to be made for threadsafe mode to work properly. Can also be enabled with +threadsafe!+. - * +config.asset_host+ sets the host for the assets. Useful when CDNs are used for hosting assets, or when you want to work around the concurrency constraints builtin in browsers using different domain aliases. Shorter version of +config.action_controller.asset_host+. * +config.asset_path+ lets you decorate asset paths. This can be a callable, a string, or be +nil+ which is the default. For example, the normal path for +blog.js+ would be +/javascripts/blog.js+, let that absolute path be +path+. If +config.asset_path+ is a callable, Rails calls it when generating asset paths passing +path+ as argument. If +config.asset_path+ is a string, it is expected to be a +sprintf+ format string with a +%s+ where +path+ will get inserted. In either case, Rails outputs the decorated path. Shorter version of +config.action_controller.asset_path+. @@ -89,6 +87,10 @@ end * +config.dependency_loading+ is a flag that allows you to disable constant autoloading setting it to false. It only has effect if +config.cache_classes+ is true, which it is by default in production mode. This flag is set to false by +config.threadsafe!+. +* +config.eager_load+ when true, eager loads all registered `config.eager_load_namespaces`. This includes your application, engines, Rails frameworks and any other registered namespace. + +* +config.eager_load_namespaces+ registers namespaces that are eager loaded when +config.eager_load+ is true. All namespaces in the list must respond to the +eager_load!+ method. + * +config.eager_load_paths+ accepts an array of paths from which Rails will eager load on boot if cache classes is enabled. Defaults to every folder in the +app+ directory of the application. * +config.encoding+ sets up the application-wide encoding. Defaults to UTF-8. @@ -109,8 +111,6 @@ end * +config.middleware+ allows you to configure the application's middleware. This is covered in depth in the "Configuring Middleware":#configuring-middleware section below. -* +config.preload_frameworks+ enables or disables preloading all frameworks at startup. Enabled by +config.threadsafe!+. Defaults to +nil+, so is disabled. - * +config.queue+ configures a different queue implementation for the application. Defaults to +Rails::Queueing::Queue+. Note that, if the default queue is changed, the default +queue_consumer+ is not going to be initialized, it is up to the new queue implementation to handle starting and shutting down its own consumer(s). * +config.queue_consumer+ configures a different consumer implementation for the default queue. Defaults to +Rails::Queueing::ThreadedConsumer+. @@ -129,10 +129,6 @@ config.session_store :my_custom_store This custom store must be defined as +ActionDispatch::Session::MyCustomStore+. In addition to symbols, they can also be objects implementing a certain API, like +ActiveRecord::SessionStore+, in which case no special namespace is required. -* +config.threadsafe!+ enables +allow_concurrency+, +cache_classes+, +dependency_loading+ and +preload_frameworks+ to make the application threadsafe. - -WARNING: Threadsafe operation is incompatible with the normal workings of development mode Rails. In particular, automatic dependency loading and class reloading are automatically disabled when you call +config.threadsafe!+. - * +config.time_zone+ sets the default time zone for the application and enables time zone awareness for Active Record. * +config.whiny_nils+ enables or disables warnings when a certain set of methods are invoked on +nil+ and it does not respond to them. Defaults to true in development and test environments. @@ -157,7 +153,7 @@ Rails 3.1, by default, is set up to use the +sprockets+ gem to manage assets wit * +config.assets.digest+ enables the use of MD5 fingerprints in asset names. Set to +true+ by default in +production.rb+. -* +config.assets.debug+ disables the concatenation and compression of assets. Set to +false+ by default in +development.rb+. +* +config.assets.debug+ disables the concatenation and compression of assets. Set to +true+ by default in +development.rb+. * +config.assets.manifest+ defines the full path to be used for the asset precompiler's manifest file. Defaults to using +config.assets.prefix+. @@ -186,7 +182,7 @@ The full set of methods that can be used in this block are as follows: * +force_plural+ allows pluralized model names. Defaults to +false+. * +helper+ defines whether or not to generate helpers. Defaults to +true+. * +integration_tool+ defines which integration tool to use. Defaults to +nil+. -* +javascripts+ turns on the hook for javascripts in generators. Used in Rails for when the +scaffold+ generator is run. Defaults to +true+. +* +javascripts+ turns on the hook for JavaScript files in generators. Used in Rails for when the +scaffold+ generator is run. Defaults to +true+. * +javascript_engine+ configures the engine to be used (for eg. coffee) when generating assets. Defaults to +nil+. * +orm+ defines which orm to use. Defaults to +false+ and will use Active Record by default. * +performance_tool+ defines which performance tool to use. Defaults to +nil+. @@ -203,7 +199,7 @@ Every Rails application comes with a standard set of middleware which it uses in * +ActionDispatch::SSL+ forces every request to be under HTTPS protocol. Will be available if +config.force_ssl+ is set to +true+. Options passed to this can be configured by using +config.ssl_options+. * +ActionDispatch::Static+ is used to serve static assets. Disabled if +config.serve_static_assets+ is +true+. -* +Rack::Lock+ wraps the app in mutex so it can only be called by a single thread at a time. Only enabled if +config.action_controller.allow_concurrency+ is set to +false+, which it is by default. +* +Rack::Lock+ wraps the app in mutex so it can only be called by a single thread at a time. Only enabled when +config.cache_classes_+ is +false+. * +ActiveSupport::Cache::Strategy::LocalCache+ serves as a basic memory backed cache. This cache is not thread safe and is intended only for serving as a temporary memory cache for a single thread. * +Rack::Runtime+ sets an +X-Runtime+ header, containing the time (in seconds) taken to execute the request. * +Rails::Rack::Logger+ notifies the logs that the request has began. After request is complete, flushes all the logs. @@ -286,8 +282,6 @@ h4. Configuring Active Record * +config.active_record.auto_explain_threshold_in_seconds+ configures the threshold for automatic EXPLAINs (+nil+ disables this feature). Queries exceeding the threshold get their query plan logged. Default is 0.5 in development mode. -* +config.active_record.dependent_restrict_raises+ will control the behavior when an object with a <tt>:dependent => :restrict</tt> association is deleted. Setting this to false will prevent +DeleteRestrictionError+ from being raised and instead will add an error on the model object. Defaults to false in the development mode. - * +config.active_record.mass_assignment_sanitizer+ will determine the strictness of the mass assignment sanitization within Rails. Defaults to +:strict+. In this mode, mass assigning any non-+attr_accessible+ attribute in a +create+ or +update_attributes+ call will raise an exception. Setting this option to +:logger+ will only print to the log file when an attribute is being assigned and will not raise an exception. The MySQL adapter adds one additional configuration option: @@ -340,6 +334,12 @@ h4. Configuring Action Dispatch * +config.action_dispatch.session_store+ sets the name of the store for session data. The default is +:cookie_store+; other valid options include +:active_record_store+, +:mem_cache_store+ or the name of your own custom class. +* +config.action_dispatch.default_headers+ is a hash with HTTP headers that are set by default in each response. By default, this is defined as: + +<ruby> +config.action_dispatch.default_headers = { 'X-Frame-Options' => 'SAMEORIGIN', 'X-XSS-Protection' => '1; mode=block', 'X-Content-Type-Options' => 'nosniff' } +</ruby> + * +config.action_dispatch.tld_length+ sets the TLD (top-level domain) length for the application. Defaults to +1+. * +ActionDispatch::Callbacks.before+ takes a block of code to run before the request. @@ -424,7 +424,7 @@ There are a number of settings available on +config.action_mailer+: * +config.action_mailer.perform_deliveries+ specifies whether mail will actually be delivered and is true by default. It can be convenient to set it to false for testing. -* +config.action_mailer.default+ configures Action Mailer defaults. These default to: +* +config.action_mailer.default_options+ configures Action Mailer defaults. Use to set options like `from` or `reply_to` for every mailer. These default to: <ruby> :mime_version => "1.0", :charset => "UTF-8", @@ -652,8 +652,6 @@ Serves as a placeholder so that +:load_environment_config+ can be defined to run *+load_active_support+* Requires +active_support/dependencies+ which sets up the basis for Active Support. Optionally requires +active_support/all+ if +config.active_support.bare+ is un-truthful, which is the default. -*+preload_frameworks+* Loads all autoload dependencies of Rails automatically if +config.preload_frameworks+ is +true+ or "truthful". By default this configuration option is disabled. In Rails, when internal classes are referenced for the first time they are autoloaded. +:preload_frameworks+ loads all of this at once on initialization. - *+initialize_logger+* Initializes the logger (an +ActiveSupport::BufferedLogger+ object) for the application and makes it accessible at +Rails.logger+, provided that no initializer inserted before this point has defined +Rails.logger+. *+initialize_cache+* If +Rails.cache+ isn't set yet, initializes the cache by referencing the value in +config.cache_store+ and stores the outcome as +Rails.cache+. If this object responds to the +middleware+ method, its middleware is inserted before +Rack::Runtime+ in the middleware stack. @@ -748,13 +746,13 @@ The error occurred while evaluating nil.each *+build_middleware_stack+* Builds the middleware stack for the application, returning an object which has a +call+ method which takes a Rack environment object for the request. -*+eager_load!+* If +config.cache_classes+ is true, runs the +config.before_eager_load+ hooks and then calls +eager_load!+ which will load all the Ruby files from +config.eager_load_paths+. +*+eager_load!+* If +config.eager_load+ is true, runs the +config.before_eager_load+ hooks and then calls +eager_load!+ which will load all +config.eager_load_namespaces+. *+finisher_hook+* Provides a hook for after the initialization of process of the application is complete, as well as running all the +config.after_initialize+ blocks for the application, railties and engines. *+set_routes_reloader+* Configures Action Dispatch to reload the routes file using +ActionDispatch::Callbacks.to_prepare+. -*+disable_dependency_loading+* Disables the automatic dependency loading if the +config.cache_classes+ is set to true and +config.dependency_loading+ is set to false. +*+disable_dependency_loading+* Disables the automatic dependency loading if the +config.eager_load+ is set to true. h3. Database pooling diff --git a/guides/source/contributing_to_ruby_on_rails.textile b/guides/source/contributing_to_ruby_on_rails.textile index acf75d41cd..4bb4e3b546 100644 --- a/guides/source/contributing_to_ruby_on_rails.textile +++ b/guides/source/contributing_to_ruby_on_rails.textile @@ -34,20 +34,28 @@ h4. What about Feature Requests? Please don't put "feature request" items into GitHub Issues. If there's a new feature that you want to see added to Ruby on Rails, you'll need to write the code yourself - or convince someone else to partner with you to write the code. Later in this guide you'll find detailed instructions for proposing a patch to Ruby on Rails. If you enter a wishlist item in GitHub Issues with no code, you can expect it to be marked "invalid" as soon as it's reviewed. -h3. Running the Test Suite +If you'd like feedback on an idea for a feature before doing the work for make a patch, please send an email to the "rails-core mailing list":https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-core. You might get no response, which means that everyone is indifferent. You might find someone who's also interested in building that feature. You might get a "This won't be accepted." But it's the proper place to discuss new ideas. GitHub Issues are not a particularly good venue for the sometimes long and involved discussions new features require. + +h3. Setting Up a Development Environment To move on from submitting bugs to helping resolve existing issues or contributing your own code to Ruby on Rails, you _must_ be able to run its test suite. In this section of the guide you'll learn how to set up the tests on your own computer. -h4. Install Git +h4. The Easy Way + +The easiest way to get a development environment ready to hack is to use the "Rails development box":https://github.com/rails/rails-dev-box. + +h4. The Hard Way + +h5. Install Git -Ruby on Rails uses git for source code control. The "git homepage":http://git-scm.com/ has installation instructions. There are a variety of resources on the net that will help you get familiar with git: +Ruby on Rails uses Git for source code control. The "Git homepage":http://git-scm.com/ has installation instructions. There are a variety of resources on the net that will help you get familiar with Git: -* "Everyday Git":http://schacon.github.com/git/everyday.html will teach you just enough about git to get by. -* The "PeepCode screencast":https://peepcode.com/products/git on git ($9) is easier to follow. -* "GitHub":http://help.github.com offers links to a variety of git resources. -* "Pro Git":http://progit.org/book/ is an entire book about git with a Creative Commons license. +* "Everyday Git":http://schacon.github.com/git/everyday.html will teach you just enough about Git to get by. +* The "PeepCode screencast":https://peepcode.com/products/git on Git ($9) is easier to follow. +* "GitHub":http://help.github.com offers links to a variety of Git resources. +* "Pro Git":http://git-scm.com/book is an entire book about Git with a Creative Commons license. -h4. Clone the Ruby on Rails Repository +h5. Clone the Ruby on Rails Repository Navigate to the folder where you want the Ruby on Rails source code (it will create its own +rails+ subdirectory) and run: @@ -56,7 +64,7 @@ $ git clone git://github.com/rails/rails.git $ cd rails </shell> -h4. Set up and Run the Tests +h5. Set up and Run the Tests The test suite must pass with any submitted code. No matter whether you are writing a new patch, or evaluating someone else's, you need to be able to run the tests. @@ -66,12 +74,26 @@ Install first libxml2 and libxslt together with their development files for Noko $ sudo apt-get install libxml2 libxml2-dev libxslt1-dev </shell> +If you are on Fedora or CentOS, you can run + +<shell> +$ sudo yum install libxml2 libxml2-devel libxslt libxslt-devel +</shell> + +If you have any problems with these libraries, you should install them manually compiling the source code. Just follow the instructions at the "Red Hat/CentOS section of the Nokogiri tutorials":http://nokogiri.org/tutorials/installing_nokogiri.html#red_hat__centos . + Also, SQLite3 and its development files for the +sqlite3-ruby+ gem -- in Ubuntu you're done with just <shell> $ sudo apt-get install sqlite3 libsqlite3-dev </shell> +And if you are on Fedora or CentOS, you're done with + +<shell> +$ sudo yum install sqlite3 sqlite3-devel +</shell> + Get a recent version of "Bundler":http://gembundler.com/: <shell> @@ -109,45 +131,33 @@ You can run any single test separately too: <shell> $ cd actionpack -$ ruby -Itest test/template/form_helper_test.rb +$ bundle exec ruby -Itest test/template/form_helper_test.rb </shell> -h4. Warnings - -The test suite runs with warnings enabled. Ideally, Ruby on Rails should issue no warnings, but there may be a few, as well as some from third-party libraries. Please ignore (or fix!) them, if any, and submit patches that do not issue new warnings. - -As of this writing (December, 2010) they are specially noisy with Ruby 1.9. If you are sure about what you are doing and would like to have a more clear output, there's a way to override the flag: - -<shell> -$ RUBYOPT=-W0 bundle exec rake test -</shell> - -h4. Testing Active Record +h5. Active Record Setup The test suite of Active Record attempts to run four times: once for SQLite3, once for each of the two MySQL gems (+mysql+ and +mysql2+), and once for PostgreSQL. We are going to see now how to set up the environment for them. WARNING: If you're working with Active Record code, you _must_ ensure that the tests pass for at least MySQL, PostgreSQL, and SQLite3. Subtle differences between the various adapters have been behind the rejection of many patches that looked OK when tested only against MySQL. -h5. Database Configuration +h6. Database Configuration The Active Record test suite requires a custom config file: +activerecord/test/config.yml+. An example is provided in +activerecord/test/config.example.yml+ which can be copied and used as needed for your environment. -h5. SQLite3 +h6. MySQL and PostgreSQL -The gem +sqlite3-ruby+ does not belong to the "db" group. Indeed, if you followed the instructions above you're ready. This is how you run the Active Record test suite only for SQLite3: +To be able to run the suite for MySQL and PostgreSQL we need their gems. Install first the servers, their client libraries, and their development files. In Ubuntu just run <shell> -$ cd activerecord -$ bundle exec rake test_sqlite3 +$ sudo apt-get install mysql-server libmysqlclient15-dev +$ sudo apt-get install postgresql postgresql-client postgresql-contrib libpq-dev </shell> -h5. MySQL and PostgreSQL - -To be able to run the suite for MySQL and PostgreSQL we need their gems. Install first the servers, their client libraries, and their development files. In Ubuntu just run +On Fedora or CentOS, just run: <shell> -$ sudo apt-get install mysql-server libmysqlclient15-dev -$ sudo apt-get install postgresql postgresql-client postgresql-contrib libpq-dev +$ sudo yum install mysql-server mysql-devel +$ sudo yum install postgresql-server postgresql-devel </shell> After that run: @@ -172,7 +182,7 @@ and create the test databases: <shell> $ cd activerecord -$ rake mysql:build_databases +$ bundle exec rake mysql:build_databases </shell> PostgreSQL's authentication works differently. A simple way to set up the development environment for example is to run with your development account @@ -185,12 +195,23 @@ and then create the test databases with <shell> $ cd activerecord -$ rake postgresql:build_databases +$ bundle exec rake postgresql:build_databases </shell> NOTE: Using the rake task to create the test databases ensures they have the correct character set and collation. -If you’re using another database, check the files under +activerecord/test/connections+ for default connection information. You can edit these files to provide different credentials on your machine if you must, but obviously you should not push any such changes back to Rails. +NOTE: You'll see the following warning (or localized warning) during activating HStore extension in PostgreSQL 9.1.x or earlier: "WARNING: => is deprecated as an operator". + +If you’re using another database, check the file +activerecord/test/config.yml+ or +activerecord/test/config.example.yml+ for default connection information. You can edit +activerecord/test/config.yml+ to provide different credentials on your machine if you must, but obviously you should not push any such changes back to Rails. + +h3. Testing Active Record + +This is how you run the Active Record test suite only for SQLite3: + +<shell> +$ cd activerecord +$ bundle exec rake test_sqlite3 +</shell> You can now run the tests as you did for +sqlite3+. The tasks are respectively @@ -200,7 +221,7 @@ test_mysql2 test_postgresql </shell> -As we mentioned before +Finally, <shell> $ bundle exec rake test @@ -216,6 +237,16 @@ $ ARCONN=sqlite3 ruby -Itest test/cases/associations/has_many_associations_test. You can invoke +test_jdbcmysql+, +test_jdbcsqlite3+ or +test_jdbcpostgresql+ also. See the file +activerecord/RUNNING_UNIT_TESTS+ for information on running more targeted database tests, or the file +ci/travis.rb+ for the test suite run by the continuous integration server. +h4. Warnings + +The test suite runs with warnings enabled. Ideally, Ruby on Rails should issue no warnings, but there may be a few, as well as some from third-party libraries. Please ignore (or fix!) them, if any, and submit patches that do not issue new warnings. + +As of this writing (December, 2010) they are specially noisy with Ruby 1.9. If you are sure about what you are doing and would like to have a more clear output, there's a way to override the flag: + +<shell> +$ RUBYOPT=-W0 bundle exec rake test +</shell> + h4. Older Versions of Ruby on Rails If you want to add a fix to older versions of Ruby on Rails, you'll need to set up and switch to your own local tracking branch. Here is an example to switch to the 3-0-stable branch: @@ -225,7 +256,7 @@ $ git branch --track 3-0-stable origin/3-0-stable $ git checkout 3-0-stable </shell> -TIP: You may want to "put your git branch name in your shell prompt":http://qugstart.com/blog/git-and-svn/add-colored-git-branch-name-to-your-shell-prompt/ to make it easier to remember which version of the code you're working with. +TIP: You may want to "put your Git branch name in your shell prompt":http://qugstart.com/blog/git-and-svn/add-colored-git-branch-name-to-your-shell-prompt/ to make it easier to remember which version of the code you're working with. h3. Helping to Resolve Existing Issues @@ -306,7 +337,7 @@ $ cd rails $ git checkout -b my_new_branch </shell> -It doesn’t matter much what name you use, because this branch will only exist on your local computer and your personal repository on Github. It won't be part of the Rails git repository. +It doesn’t matter much what name you use, because this branch will only exist on your local computer and your personal repository on Github. It won't be part of the Rails Git repository. h4. Write Your Code @@ -317,6 +348,8 @@ Now get busy and add or edit code. You’re on your branch now, so you can write * Include tests that fail without your code, and pass with it. * Update the (surrounding) documentation, examples elsewhere, and the guides: whatever is affected by your contribution. +TIP: Changes that are cosmetic in nature and do not add anything substantial to the stability, functionality, or testability of Rails will generally not be accepted. + h4. Follow the Coding Conventions Rails follows a simple set of coding style conventions. @@ -332,6 +365,31 @@ Rails follows a simple set of coding style conventions. The above are guidelines -- please use your best judgment in using them. +h4. Updating the CHANGELOG + +The CHANGELOG is an important part of every release. It keeps the list of changes for every Rails version. + +You should add an entry to the CHANGELOG of the framework that you modified if you're adding or removing a feature, commiting a bug fix or adding deprecation notices. Refactorings and documentation changes generally should not go to the CHANGELOG. + +A CHANGELOG entry should summarize what was changed and should end with author's name. You can use multiple lines if you need more space and you can attach code examples indented with 4 spaces. If a change is related to a specific issue, you should attach issue's number. Here is an example CHANGELOG entry: + +<plain> +* Summary of a change that briefly describes what was changed. You can use multiple + lines and wrap them at around 80 characters. Code examples are ok, too, if needed: + + class Foo + def bar + puts 'baz' + end + end + + You can continue after the code example and you can attach issue number. GH#1234 + + * Your Name * +</plain> + +Your name can be added directly after the last word if you don't provide any code examples or don't need multiple paragraphs. Otherwise, it's best to make as a new paragraph. + h4. Sanity Check You should not be the only person who looks at the code before you submit it. You know at least one other Rails developer, right? Show them what you’re doing and ask for feedback. Doing this in private before you push a patch out publicly is the “smoke test” for a patch: if you can’t convince one other developer of the beauty of your code, you’re unlikely to convince the core team either. @@ -340,7 +398,7 @@ You might want also to check out the "RailsBridge BugMash":http://wiki.railsbrid h4. Commit Your Changes -When you're happy with the code on your computer, you need to commit the changes to git: +When you're happy with the code on your computer, you need to commit the changes to Git: <shell> $ git commit -a @@ -359,7 +417,7 @@ the commit content is obvious, it may not be obvious to others. You should add such description also if it's already present in bug tracker, it should not be necessary to visit a webpage to check the history. -Description can have multiple paragraps and you can use code examples +Description can have multiple paragraphs and you can use code examples inside, just indent it with 4 spaces: class PostsController @@ -468,9 +526,9 @@ It’s entirely possible that the feedback you get will suggest changes. Don’t h4. Backporting -Changes that are merged into master are intended for the next major release of Rails. Sometimes, it might be beneficial for your changes to propagate back to the maintenance releases for older stable branches. Generally, security fixes and bug fixes are good candidates for a backport, while new features and patches that introduce a change in behavior will not be accepted. When in doubt, it is best to consult a rails team member before backporting your changes to avoid wasted effort. +Changes that are merged into master are intended for the next major release of Rails. Sometimes, it might be beneficial for your changes to propagate back to the maintenance releases for older stable branches. Generally, security fixes and bug fixes are good candidates for a backport, while new features and patches that introduce a change in behavior will not be accepted. When in doubt, it is best to consult a Rails team member before backporting your changes to avoid wasted effort. -For simple fixes, the easiest way to backport your change is to "extract a diff from your changes in master and apply them to the target branch":http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git. +For simple fixes, the easiest way to backport your changes is to "extract a diff from your changes in master and apply them to the target branch":http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git. First make sure your changes are the only difference between your current branch and master: @@ -493,9 +551,9 @@ $ git apply ~/my_changes.patch This works well for simple changes. However, if your changes are complicated or if the code in master has deviated significantly from your target branch, it might require more work on your part. The difficulty of a backport varies greatly from case to case, and sometimes it is simply not worth the effort. -Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the ruby versions listed in +.travis.yml+ before submitting your pull request. +Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the Ruby versions listed in +.travis.yml+ before submitting your pull request. -And then ... think about your next contribution! +And then... think about your next contribution! h3. Rails Contributors diff --git a/guides/source/debugging_rails_applications.textile b/guides/source/debugging_rails_applications.textile index 0802a2db26..667f2d2140 100644 --- a/guides/source/debugging_rails_applications.textile +++ b/guides/source/debugging_rails_applications.textile @@ -102,7 +102,7 @@ It can also be useful to save information to log files at runtime. Rails maintai h4. What is the Logger? -Rails makes use of Ruby's standard +logger+ to write log information. You can also substitute another logger such as +Log4r+ if you wish. +Rails makes use of the +ActiveSupport::BufferedLogger+ class to write log information. You can also substitute another logger such as +Log4r+ if you wish. You can specify an alternative logger in your +environment.rb+ or any environment file: @@ -626,7 +626,7 @@ In this section, you will learn how to find and fix such leaks by using tools su h4. BleakHouse -"BleakHouse":https://github.com/fauna/bleak_house/tree/master is a library for finding memory leaks. +"BleakHouse":https://github.com/evan/bleak_house/ is a library for finding memory leaks. If a Ruby object does not go out of scope, the Ruby Garbage Collector won't sweep it since it is referenced somewhere. Leaks like this can grow slowly and your application will consume more and more memory, gradually affecting the overall system performance. This tool will help you find leaks on the Ruby heap. @@ -675,7 +675,7 @@ To analyze it, just run the listed command. The top 20 leakiest lines will be li This way you can find where your application is leaking memory and fix it. -If "BleakHouse":https://github.com/fauna/bleak_house/tree/master doesn't report any heap growth but you still have memory growth, you might have a broken C extension, or real leak in the interpreter. In that case, try using Valgrind to investigate further. +If "BleakHouse":https://github.com/evan/bleak_house/ doesn't report any heap growth but you still have memory growth, you might have a broken C extension, or real leak in the interpreter. In that case, try using Valgrind to investigate further. h4. Valgrind @@ -708,4 +708,4 @@ h3. References * "Debugging with ruby-debug":http://bashdb.sourceforge.net/ruby-debug.html * "ruby-debug cheat sheet":http://cheat.errtheblog.com/s/rdebug/ * "Ruby on Rails Wiki: How to Configure Logging":http://wiki.rubyonrails.org/rails/pages/HowtoConfigureLogging -* "Bleak House Documentation":http://blog.evanweaver.com/files/doc/fauna/bleak_house/files/README.html +* "Bleak House Documentation":http://blog.evanweaver.com/files/doc/fauna/bleak_house/ diff --git a/guides/source/engines.textile b/guides/source/engines.textile index 86e7254201..de4bbb5656 100644 --- a/guides/source/engines.textile +++ b/guides/source/engines.textile @@ -347,7 +347,7 @@ The form will be making a +POST+ request to +/posts/:post_id/comments+, which wi <ruby> def create @post = Post.find(params[:post_id]) - @comment = @post.comments.build(params[:comment]) + @comment = @post.comments.create(params[:comment]) flash[:notice] = "Comment has been created!" redirect_to post_path end @@ -563,7 +563,7 @@ end By default, the engine's controllers inherit from <tt>Blorgh::ApplicationController</tt>. So, after making this change they will have access to the main applications +ApplicationController+ as though they were part of the main application. -This change does require that the engine is run from a Rails application that has an +ApplicationController+. +This change does require that the engine is run from a Rails application that has an +ApplicationController+. h4. Configuring an engine @@ -655,7 +655,125 @@ This tells the application that you still want to perform a +GET+ request to the h3. Improving engine functionality -This section looks at overriding or adding functionality to the views, controllers and models provided by an engine. +This section explains how to add and/or override engine MVC functionality in the main Rails application. + +h4. Overriding Models and Controllers + +Engine model and controller classes can be extended by open classing them in the main Rails application (since model and controller classes are just Ruby classes that inherit Rails specific functionality). Open classing an Engine class redefines it for use in the main applicaiton. This is usually implemented by using the decorator pattern. + +For simple class modifications use Class#class_eval, and for complex class modifications, consider using ActiveSupport::Concern. + +h5. Implementing Decorator Pattern Using Class#class_eval + +**Adding** Post#time_since_created, + +<ruby> +# MyApp/app/decorators/models/blorgh/post_decorator.rb + +Blorgh::Post.class_eval do + def time_since_created + Time.current - created_at + end +end +</ruby> + +<ruby> +# Blorgh/app/models/post.rb + +class Post < ActiveRecord::Base + :has_many :comments +end +</ruby> + + +**Overriding** Post#summary + +<ruby> +# MyApp/app/decorators/models/blorgh/post_decorator.rb + +Blorgh::Post.class_eval do + def summary + "#{title} - #{truncate(text)}" + end +end +</ruby> + +<ruby> +# Blorgh/app/models/post.rb + +class Post < ActiveRecord::Base + :has_many :comments + def summary + "#{title}" + end +end +</ruby> + + +h5. Implementing Decorator Pattern Using ActiveSupport::Concern + +Using Class#class_eval is great for simple adjustments, but for more complex class modifications, you might want to consider using ActiveSupport::Concern. ["**ActiveSupport::Concern**":http://edgeapi.rubyonrails.org/classes/ActiveSupport/Concern.html] helps manage load order of interlinked dependencies at run time allowing you to significantly modularize your code. + +**Adding** Post#time_since_created<br/> +**Overriding** Post#summary + +<ruby> +# MyApp/app/models/blorgh/post.rb + +class Blorgh::Post < ActiveRecord::Base + include Blorgh::Concerns::Models::Post + + def time_since_created + Time.current - created_at + end + + def summary + "#{title} - #{truncate(text)}" + end +end +</ruby> + +<ruby> +# Blorgh/app/models/post.rb + +class Post < ActiveRecord::Base + include Blorgh::Concerns::Models::Post +end +</ruby> + +<ruby> +# Blorgh/lib/concerns/models/post + +module Blorgh::Concerns::Models::Post + extend ActiveSupport::Concern + + # 'included do' causes the included code to be evaluated in the + # conext where it is included (post.rb), rather than be + # executed in the module's context (blorgh/concerns/models/post). + included do + attr_accessor :author_name + belongs_to :author, :class_name => "User" + + before_save :set_author + + private + + def set_author + self.author = User.find_or_create_by_name(author_name) + end + end + + def summary + "#{title}" + end + + module ClassMethods + def some_class_method + 'some class method string' + end + end +end +</ruby> h4. Overriding views @@ -734,12 +852,14 @@ You can also specify these assets as dependencies of other assets using the Asse */ </plain> +INFO. Remember that in order to use languages like Sass or CoffeeScript, you should add the relevant library to your engine's +.gemspec+. + h4. Separate Assets & Precompiling There are some situations where your engine's assets not required by the host application. For example, say that you've created an admin functionality that only exists for your engine. In this case, the host application doesn't need to require +admin.css+ or +admin.js+. Only the gem's admin layout needs these assets. It doesn't make sense for the host app to include +"blorg/admin.css"+ in it's stylesheets. In this situation, you should explicitly define these assets for precompilation. -This tells sprockets to add you engine assets when +rake assets:precompile+ is ran. +This tells sprockets to add you engine assets when +rake assets:precompile+ is ran. You can define assets for precompilation in +engine.rb+ @@ -753,18 +873,40 @@ For more information, read the "Asset Pipeline guide":http://guides.rubyonrails. h4. Other gem dependencies -Gem dependencies inside an engine should be specified inside the +.gemspec+ file that's at the root of the engine. The reason for this is because the engine may be installed as a gem. If dependencies were to be specified inside the +Gemfile+, these would not be recognised by a traditional gem install and so they would not be installed, causing the engine to malfunction. +Gem dependencies inside an engine should be specified inside the +.gemspec+ file +that's at the root of the engine. The reason for this is because the engine may +be installed as a gem. If dependencies were to be specified inside the +Gemfile+, +these would not be recognised by a traditional gem install and so they would not +be installed, causing the engine to malfunction. -To specify a dependency that should be installed with the engine during a traditional +gem install+, specify it inside the +Gem::Specification+ block inside the +.gemspec+ file in the engine: +To specify a dependency that should be installed with the engine during a +traditional +gem install+, specify it inside the +Gem::Specification+ block +inside the +.gemspec+ file in the engine: <ruby> s.add_dependency "moo" </ruby> -To specify a dependency that should only be installed as a development dependency of the application, specify it like this: +To specify a dependency that should only be installed as a development +dependency of the application, specify it like this: <ruby> s.add_development_dependency "moo" </ruby> -Both kinds of dependencies will be installed when +bundle install+ is run inside the application. The development dependencies for the gem will only be used when the tests for the engine are running. +Both kinds of dependencies will be installed when +bundle install+ is run inside +the application. The development dependencies for the gem will only be used when +the tests for the engine are running. + +Note that if you want to immediately require dependencies when the engine is +required, you should require them before engine's initialization. For example: + +<ruby> +require 'other_engine/engine' +require 'yet_another_engine/engine' + +module MyEngine + class Engine < ::Rails::Engine + end +end +</ruby>
\ No newline at end of file diff --git a/guides/source/form_helpers.textile b/guides/source/form_helpers.textile index 8106de6f9d..58338ce54b 100644 --- a/guides/source/form_helpers.textile +++ b/guides/source/form_helpers.textile @@ -10,7 +10,7 @@ In this guide you will: * Understand the date and time helpers Rails provides * Learn what makes a file upload form different * Learn some cases of building forms to external resources -* Find out where to look for complex forms +* Find out how to build complex forms endprologue. @@ -419,6 +419,18 @@ TIP: The second argument to +options_for_select+ must be exactly equal to the de WARNING: when +:inlude_blank+ or +:prompt:+ are not present, +:include_blank+ is forced true if the select attribute +required+ is true, display +size+ is one and +multiple+ is not true. +You can add arbitrary attributes to the options using hashes: + +<erb> +<%= options_for_select([['Lisbon', 1, :'data-size' => '2.8 million'], ['Madrid', 2, :'data-size' => '3.2 million']], 2) %> + +output: + +<option value="1" data-size="2.8 million">Lisbon</option> +<option value="2" selected="selected" data-size="3.2 million">Madrid</option> +... +</erb> + h4. Select Boxes for Dealing with Models In most cases form controls will be tied to a specific database model and as you might expect Rails provides helpers tailored for that purpose. Consistent with other form helpers, when dealing with models you drop the +_tag+ suffix from +select_tag+: @@ -804,11 +816,130 @@ Or if you don't want to render an +authenticity_token+ field: h3. Building Complex Forms -Many apps grow beyond simple forms editing a single object. For example when creating a Person you might want to allow the user to (on the same form) create multiple address records (home, work, etc.). When later editing that person the user should be able to add, remove or amend addresses as necessary. While this guide has shown you all the pieces necessary to handle this, Rails does not yet have a standard end-to-end way of accomplishing this, but many have come up with viable approaches. These include: +Many apps grow beyond simple forms editing a single object. For example when creating a Person you might want to allow the user to (on the same form) create multiple address records (home, work, etc.). When later editing that person the user should be able to add, remove or amend addresses as necessary. + +h4. Configuring the Model + +Active Record provides model level support via the +accepts_nested_attributes_for+ method: + +<ruby> +class Person < ActiveRecord::Base + has_many :addresses + accepts_nested_attributes_for :addresses + + attr_accessible :name, :addresses_attributes +end + +class Address < ActiveRecord::Base + belongs_to :person + attr_accessible :kind, :street +end +</ruby> + +This creates an +addresses_attributes=+ method on +Person+ that allows you to create, update and (optionally) destroy addresses. When using +attr_accessible+ or +attr_protected+ you must mark +addresses_attributes+ as accessible as well as the other attributes of +Person+ and +Address+ that should be mass assigned. + +h4. Building the Form + +The following form allows a user to create a +Person+ and its associated addresses. + +<erb> +<%= form_for @person do |f| %> + Addresses: + <ul> + <%= f.fields_for :addresses do |addresses_form| %> + <li> + <%= addresses_form.label :kind %> + <%= addresses_form.text_field :kind %> + + <%= addresses_form.label :street %> + <%= addresses_form.text_field :street %> + ... + </li> + <% end %> + </ul> +<% end %> +</erb> + + +When an association accepts nested attributes +fields_for+ renders its block once for every element of the association. In particular, if a person has no addresses it renders nothing. A common pattern is for the controller to build one or more empty children so that at least one set of fields is shown to the user. The example below would result in 3 sets of address fields being rendered on the new person form. + +<ruby> +def new + @person = Person.new + 3.times { @person.addresses.build} +end +</ruby> + ++fields_for+ yields a form builder that names parameters in the format expected the accessor generated by +accepts_nested_attributes_for+. For example when creating a user with 2 addresses, the submitted parameters would look like + +<ruby> +{ + :person => { + :name => 'John Doe', + :addresses_attributes => { + '0' => { + :kind => 'Home', + :street => '221b Baker Street', + }, + '1' => { + :kind => 'Office', + :street => '31 Spooner Street' + } + } + } +} +</ruby> + +The keys of the +:addresses_attributes+ hash are unimportant, they need merely be different for each address. + +If the associated object is already saved, +fields_for+ autogenerates a hidden input with the +id+ of the saved record. You can disable this by passing +:include_id => false+ to +fields_for+. You may wish to do this if the autogenerated input is placed in a location where an input tag is not valid HTML or when using an ORM where children do not have an id. + +h4. The Controller + +You do not need to write any specific controller code to use nested attributes. Create and update records as you would with a simple form. + +h4. Removing Objects + +You can allow users to delete associated objects by passing +allow_destroy => true+ to +accepts_nested_attributes_for+ + +<ruby> +class Person < ActiveRecord::Base + has_many :addresses + accepts_nested_attributes_for :addresses, :allow_destroy => true +end +</ruby> + +If the hash of attributes for an object contains the key +_destroy+ with a value of '1' or 'true' then the object will be destroyed. This form allows users to remove addresses: + +<erb> +<%= form_for @person do |f| %> + Addresses: + <ul> + <%= f.fields_for :addresses do |addresses_form| %> + <li> + <%= check_box :_destroy%> + <%= addresses_form.label :kind %> + <%= addresses_form.text_field :kind %> + ... + </li> + <% end %> + </ul> +<% end %> +</erb> + +h4. Preventing Empty Records + +It is often useful to ignore sets of fields that the user has not filled in. You can control this by passing a +:reject_if+ proc to +accepts_nested_attributes_for+. This proc will be called with each hash of attributes submitted by the form. If the proc returns +false+ then Active Record will not build an associated object for that hash. The example below only tries to build an address if the +kind+ attribute is set. + +<ruby> +class Person < ActiveRecord::Base + has_many :addresses + accepts_nested_attributes_for :addresses, :reject_if => lambda {|attributes| attributes['kind'].blank?} +end +</ruby> + +As a convenience you can instead pass the symbol +:all_blank+ which will create a proc that will reject records where all the attributes are blank excluding any value for +_destroy+. + +h4. Adding Fields on the Fly -* As of Rails 2.3, Rails includes "Nested Attributes":./2_3_release_notes.html#nested-attributes and "Nested Object Forms":./2_3_release_notes.html#nested-object-forms -* Ryan Bates' series of Railscasts on "complex forms":http://railscasts.com/episodes/75 -* Handle Multiple Models in One Form from "Advanced Rails Recipes":http://media.pragprog.com/titles/fr_arr/multiple_models_one_form.pdf -* Eloy Duran's "complex-forms-examples":https://github.com/alloy/complex-form-examples/ application -* Lance Ivy's "nested_assignment":https://github.com/cainlevy/nested_assignment/tree/master plugin and "sample application":https://github.com/cainlevy/complex-form-examples/tree/cainlevy -* James Golick's "attribute_fu":https://github.com/jamesgolick/attribute_fu plugin +Rather than rendering multiple sets of fields ahead of time you may wish to add them only when a user clicks on an 'Add new child' button. Rails does not provide any builtin support for this. When generating new sets of fields you must ensure the the key of the associated array is unique - the current javascript date (milliseconds after the epoch) is a common choice.
\ No newline at end of file diff --git a/guides/source/getting_started.textile b/guides/source/getting_started.textile index f25e0c0200..22da369a2a 100644 --- a/guides/source/getting_started.textile +++ b/guides/source/getting_started.textile @@ -20,13 +20,7 @@ application from scratch. It does not assume that you have any prior experience with Rails. However, to get the most out of it, you need to have some prerequisites installed: -* The "Ruby":http://www.ruby-lang.org/en/downloads language version 1.8.7 or higher - -TIP: Note that Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails -3.0. 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 -on Rails 3.0, so if you want to use Rails 3 with 1.9.x jump on 1.9.2 or -1.9.3 for smooth sailing. +* The "Ruby":http://www.ruby-lang.org/en/downloads language version 1.9.3 or higher * The "RubyGems":http://rubyforge.org/frs/?group_id=126 packaging system ** If you want to learn more about RubyGems, please read the "RubyGems User Guide":http://docs.rubygems.org/read/book/1 @@ -216,12 +210,12 @@ You need to do this because Rails will serve any static file in the +public+ dir Next, you have to tell Rails where your actual home page is located. -Open the file +config/routes.rb+ in your editor. +Open the file +config/routes.rb+ in your editor. <ruby> Blog::Application.routes.draw do get "welcome/index" - + # The priority is based upon order of creation: # first created -> highest priority. # ... @@ -379,7 +373,7 @@ Edit the +form_for+ line inside +app/views/posts/new.html.erb+ to look like this In this example, a +Hash+ object is passed to the +:url+ option. What Rails will do with this is that it will point the form to the +create+ action of the current controller, the +PostsController+, and will send a +POST+ request to that route. For this to work, you will need to add a route to +config/routes.rb+, right underneath the one for "posts/new": <ruby> -post "posts/create" +post "posts" => "posts#create" </ruby> By using the +post+ method rather than the +get+ method, Rails will define a route that will only respond to POST methods. The POST method is the typical method used by forms all over the web. @@ -906,7 +900,7 @@ end </ruby> The new method, +update_attributes+, is used when you want to update a record -that already exists, and it accepts an hash containing the attributes +that already exists, and it accepts a hash containing the attributes that you want to update. As before, if there was an error updating the post we want to show the form back to the user. @@ -1070,13 +1064,13 @@ received an error before. <shell> # rake routes - posts GET /posts(.:format) posts#index - posts_new GET /posts/new(.:format) posts#new -posts_create POST /posts/create(.:format) posts#create - GET /posts/:id(.:format) posts#show - GET /posts/:id/edit(.:format) posts#edit - PUT /posts/:id(.:format) posts#update - root / welcome#index + posts GET /posts(.:format) posts#index +posts_new GET /posts/new(.:format) posts#new + POST /posts(.:format) posts#create + GET /posts/:id(.:format) posts#show + GET /posts/:id/edit(.:format) posts#edit + PUT /posts/:id(.:format) posts#update + root / welcome#index </shell> To fix this, open +config/routes.rb+ and modify the +get "posts/:id"+ @@ -1150,7 +1144,7 @@ together. <td><%= post.text %></td> <td><%= link_to 'Show', :action => :show, :id => post.id %></td> <td><%= link_to 'Edit', :action => :edit, :id => post.id %></td> - <td><%= link_to 'Destroy', { :action => :destroy, :id => post.id }, :method => :delete, :confirm => 'Are you sure?' %></td> + <td><%= link_to 'Destroy', { :action => :destroy, :id => post.id }, :method => :delete, :data => { :confirm => 'Are you sure?' } %></td> </tr> <% end %> </table> @@ -1158,13 +1152,12 @@ together. Here we're using +link_to+ in a different way. We wrap the +:action+ and +:id+ attributes in a hash so that we can pass those two keys in -first as one argument, and then the final two keys as another argument. The +:method+ and +:confirm+ +first as one argument, and then the final two keys as another argument. The +:method+ and +:'data-confirm'+ options are used as HTML5 attributes so that when the link is clicked, -Rails will first show a confirm dialog to the user, and then submit the -link with method +delete+. This is done via the JavaScript file +jquery_ujs+ -which is automatically included into your application's layout -(+app/views/layouts/application.html.erb+) when you generated the application. -Without this file, the confirmation dialog box wouldn't appear. +Rails will first show a confirm dialog to the user, and then submit the link with method +delete+. +This is done via the JavaScript file +jquery_ujs+ which is automatically included +into your application's layout (+app/views/layouts/application.html.erb+) when you +generated the application. Without this file, the confirmation dialog box wouldn't appear. !images/getting_started/confirm_dialog.png(Confirm Dialog)! @@ -1182,7 +1175,7 @@ declaring separate routes with the appropriate verbs into <ruby> get "posts" => "posts#index" get "posts/new" -post "posts/create" +post "posts" => "posts#create" get "posts/:id" => "posts#show", :as => :post get "posts/:id/edit" => "posts#edit" put "posts/:id" => "posts#update" @@ -1191,7 +1184,7 @@ delete "posts/:id" => "posts#destroy" That's a lot to type for covering a single *resource*. Fortunately, Rails provides a +resources+ method which can be used to declare a -standard REST resource. Here's how +config/routes/rb+ looks after the +standard REST resource. Here's how +config/routes.rb+ looks after the cleanup: <ruby> @@ -1254,6 +1247,7 @@ First, take a look at +comment.rb+: <ruby> class Comment < ActiveRecord::Base belongs_to :post + attr_accessible :body, :commenter end </ruby> @@ -1632,8 +1626,8 @@ So first, let's add the delete link in the <p> <%= link_to 'Destroy Comment', [comment.post, comment], - :confirm => 'Are you sure?', - :method => :delete %> + :method => :delete, + :data => { :confirm => 'Are you sure?' } %> </p> </erb> diff --git a/guides/source/i18n.textile b/guides/source/i18n.textile index ee7176a6c8..67863e590c 100644 --- a/guides/source/i18n.textile +++ b/guides/source/i18n.textile @@ -220,7 +220,7 @@ Every helper method dependent on +url_for+ (e.g. helpers for named routes like + You may be satisfied with this. It does impact the readability of URLs, though, when the locale "hangs" at the end of every URL in your application. Moreover, from the architectural standpoint, locale is usually hierarchically above the other parts of the application domain: and URLs should reflect this. -You probably want URLs to look like this: +www.example.com/en/books+ (which loads the English locale) and +www.example.com/nl/books+ (which loads the Dutch locale). This is achievable with the "over-riding +default_url_options+" strategy from above: you just have to set up your routes with "+path_prefix+":http://api.rubyonrails.org/classes/ActionController/Resources.html#M000354 option in this way: +You probably want URLs to look like this: +www.example.com/en/books+ (which loads the English locale) and +www.example.com/nl/books+ (which loads the Dutch locale). This is achievable with the "over-riding +default_url_options+" strategy from above: you just have to set up your routes with "+scoping+":http://api.rubyonrails.org/classes/ActionDispatch/Routing/Mapper/Scoping.html option in this way: <ruby> # config/routes.rb @@ -405,6 +405,10 @@ So that would give you: TIP: Right now you might need to add some more date/time formats in order to make the I18n backend work as expected (at least for the 'pirate' locale). Of course, there's a great chance that somebody already did all the work by *translating Rails' defaults for your locale*. See the "rails-i18n repository at Github":https://github.com/svenfuchs/rails-i18n/tree/master/rails/locale for an archive of various locale files. When you put such file(s) in +config/locales/+ directory, they will automatically be ready for use. +h4. Inflection Rules For Other Locales + +Rails 4.0 allows you to define inflection rules (such as rules for singularization and pluralization) for locales other than English. In +config/initializers/inflections.rb+, you can define these rules for multiple locales. The initializer contains a default example for specifying additional rules for English; follow that format for other locales as you see fit. + h4. Localized Views Rails 2.3 introduces another convenient localization feature: localized views (templates). Let's say you have a _BooksController_ in your application. Your _index_ action renders content in +app/views/books/index.html.erb+ template. When you put a _localized variant_ of this template: *+index.es.html.erb+* in the same directory, Rails will render content in this template, when the locale is set to +:es+. When the locale is set to the default locale, the generic +index.html.erb+ view will be used. (Future Rails versions may well bring this _automagic_ localization to assets in +public+, etc.) @@ -561,7 +565,7 @@ I18n.translate :thanks, :name => 'Jeremy' # => 'Thanks Jeremy!' </ruby> -If a translation uses +:default+ or +:scope+ as an interpolation variable, an I+18n::ReservedInterpolationKey+ exception is raised. If a translation expects an interpolation variable, but this has not been passed to +#translate+, an +I18n::MissingInterpolationArgument+ exception is raised. +If a translation uses +:default+ or +:scope+ as an interpolation variable, an +I18n::ReservedInterpolationKey+ exception is raised. If a translation expects an interpolation variable, but this has not been passed to +#translate+, an +I18n::MissingInterpolationArgument+ exception is raised. h4. Pluralization diff --git a/guides/source/initialization.textile b/guides/source/initialization.textile index 48d4373afe..b23f31cb1a 100644 --- a/guides/source/initialization.textile +++ b/guides/source/initialization.textile @@ -4,18 +4,25 @@ This guide explains the internals of the initialization process in Rails as of Rails 4. It is an extremely in-depth guide and recommended for advanced Rails developers. * Using +rails server+ -* Using Passenger endprologue. -This guide goes through every single file, class and method call that is -required to boot up the Ruby on Rails stack for a default Rails 4 application, explaining each part in detail along the way. For this guide, we will be focusing on how the two most common methods (+rails server+ and Passenger) boot a Rails application. +This guide goes through every method call that is +required to boot up the Ruby on Rails stack for a default Rails 4 +application, explaining each part in detail along the way. For this +guide, we will be focusing on what happens when you execute +rails +server+ to boot your app. NOTE: Paths in this guide are relative to Rails or a Rails application unless otherwise specified. +TIP: If you want to follow along while browsing the Rails "source +code":https://github.com/rails/rails, we recommend that you use the +t+ +key binding to open the file finder inside GitHub and find files +quickly. + h3. Launch! -As of Rails 3, +script/server+ has become +rails server+. This was done to centralize all rails related commands to one common file. +A Rails application is usually started with the command +rails server+. h4. +bin/rails+ @@ -32,7 +39,7 @@ require "rails/cli" </ruby> This file will first attempt to push the +railties/lib+ directory if -present, and then require +rails/cli+. +present, and then requires +rails/cli+. h4. +railties/lib/rails/cli.rb+ @@ -121,8 +128,13 @@ exec RUBY, SCRIPT_RAILS, *ARGV if in_rails_application? This is effectively the same as running +ruby script/rails [arguments]+, where +[arguments]+ at this point in time is simply "server". +h3. Rails Initialization + +Only now we finally start the real initialization process, beginning +with +script/rails+. + TIP: If you execute +script/rails+ directly from your Rails app you will -avoid executing the code that we just described. +skip executing all the code that we've just described. h4. +script/rails+ @@ -224,47 +236,23 @@ when 'server' } </ruby> -This file will change into the root of the directory (a path two directories back from +APP_PATH+ which points at +config/application.rb+), but only if the +config.ru+ file isn't found. This then requires +rails/commands/server+ which requires +action_dispatch+ and sets up the +Rails::Server+ class. - -h4. +actionpack/lib/action_dispatch.rb+ - -Action Dispatch is the routing component of the Rails framework. It depends on Active Support, +actionpack/lib/action_pack.rb+ and +Rack+ being available. The first thing required here is +active_support+. - -h4. +activesupport/lib/active_support.rb+ - -This file begins with requiring +active_support/lib/active_support/dependencies/autoload.rb+ which redefines Ruby's +autoload+ method to have a little more extra behaviour especially in regards to eager autoloading. Eager autoloading is the loading of all required classes and will happen when the +config.cache_classes+ setting is +true+. The required file also requires another file: +active_support/lazy_load_hooks+ - -h4. +activesupport/lib/active_support/lazy_load_hooks.rb+ - -This file defines the +ActiveSupport.on_load+ hook which is used to execute code when specific parts are loaded. We'll see this in use a little later on. - -This file begins with requiring +active_support/inflector/methods+. - -h4. +activesupport/lib/active_support/inflector/methods.rb+ - -The +methods.rb+ file is responsible for defining methods such as +camelize+, +underscore+ and +dasherize+ as well as a slew of others. The "+ActiveSupport::Inflector+ documentation":http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html covers them all pretty decently. - -In this file there are a lot of lines such as this inside the +ActiveSupport+ module: +This file will change into the root of the directory (a path two directories back from +APP_PATH+ which points at +config/application.rb+), but only if the +config.ru+ file isn't found. This then requires +rails/commands/server+ which sets up the +Rails::Server+ class. <ruby> -autoload :Inflector -</ruby> +require 'fileutils' +require 'optparse' +require 'action_dispatch' -Due to the overriding of the +autoload+ method, Ruby will know how to look for this file at +activesupport/lib/active_support/inflector.rb+ when the +Inflector+ class is first referenced. - -The +active_support/lib/active_support/version.rb+ that is also required here simply defines an +ActiveSupport::VERSION+ constant which defines a couple of constants inside this module, the main constant of this is +ActiveSupport::VERSION::STRING+ which returns the current version of ActiveSupport. - -The +active_support/lib/active_support.rb+ file simply defines the +ActiveSupport+ module and some autoloads (eager and of the normal variety) for it. - -h4. +actionpack/lib/action_dispatch.rb+ cont'd. - -Now back to +action_pack/lib/action_dispatch.rb+. The next +require+ in this file is one for +action_pack+, which simply calls +action_pack/version.rb+ which defines +ActionPack::VERSION+ and the constants, much like +ActiveSpport+ does. +module Rails + class Server < ::Rack::Server +</ruby> -After this line, there's a require to +active_model+ which simply defines autoloads for the +ActiveModel+ part of Rails and sets up the +ActiveModel+ module which is used later on. ++fileutils+ and +optparse+ are standard Ruby libraries which provide helper functions for working with files and parsing options. -The last of the requires is to +rack+, which like the +active_model+ and +active_support+ requires before it, sets up the +Rack+ module as well as the autoloads for constants within it. +h4. +actionpack/lib/action_dispatch.rb+ -Finally in +action_dispatch.rb+ the +ActionDispatch+ module and *its* autoloads are declared. +Action Dispatch is the routing component of the Rails framework. +It adds functionalities like routing, session, and common middlewares. h4. +rails/commands/server.rb+ @@ -363,11 +351,20 @@ def parse!(args) ... </ruby> -This method will set up keys for the +options+ which Rails will then be able to use to determine how its server should run. After +initialize+ has finished, then the +start+ method will launch the server. +This method will set up keys for the +options+ which Rails will then be +able to use to determine how its server should run. After +initialize+ +has finished, we jump back into +rails/server+ where +APP_PATH+ (which was +set earlier) is required. + +h4. +config/application+ + +When +require APP_PATH+ is executed, +config/application.rb+ is loaded. +This file exists in your app and it's free for you to change based +on your needs. h4. +Rails::Server#start+ -This method is defined like this: +After +congif/application+ is loaded, +server.start+ is called. This method is defined like this: <ruby> def start @@ -405,7 +402,7 @@ method creates a trap for +INT+ signals, so if you +CTRL-C+ the server, it will exit the process. As we can see from the code here, it will create the +tmp/cache+, +tmp/pids+, +tmp/sessions+ and +tmp/sockets+ directories. It then calls +wrapped_app+ which is responsible for -creating the Rack app, before creating and assignig an +creating the Rack app, before creating and assigning an instance of +ActiveSupport::Logger+. The +super+ method will call +Rack::Server.start+ which begins its definition like this: @@ -455,7 +452,8 @@ end </ruby> The interesting part for a Rails app is the last line, +server.run+. Here we encounter the +wrapped_app+ method again, which this time -we're going to explore more. +we're going to explore more (even though it was executed before, and +thus memorized by now). <ruby> @wrapped_app ||= build_app app @@ -494,7 +492,7 @@ app = eval "Rack::Builder.new {( " <plus> cfgfile <plus> "\n )}.to_app", TOPLEVEL_BINDING, config </ruby> -The +initialize+ method will take the block here and execute it within an instance of +Rack::Builder+. This is where the majority of the initialization process of Rails happens. The chain of events that this simple line sets off will be the focus of a large majority of this guide. The +require+ line for +config/environment.rb+ in +config.ru+ is the first to run: +The +initialize+ method of +Rack::Builder+ will take the block here and execute it within an instance of +Rack::Builder+. This is where the majority of the initialization process of Rails happens. The +require+ line for +config/environment.rb+ in +config.ru+ is the first to run: <ruby> require ::File.expand_path('../config/environment', __FILE__) @@ -522,7 +520,7 @@ require 'rails/all' h4. +railties/lib/rails/all.rb+ -This file is responsible for requiring all the individual parts of Rails like so: +This file is responsible for requiring all the individual frameworks of Rails: <ruby> require "rails" @@ -541,641 +539,128 @@ require "rails" end </ruby> -First off the line is the +rails+ require itself. - -h4. +railties/lib/rails.rb+ +This is where all the Rails frameworks are loaded and thus made +available to the application. We won't go into detail of what happens +inside each of those frameworks, but you're encouraged to try and +explore them on your own. -This file is responsible for the initial definition of the +Rails+ -module and, rather than defining the autoloads like +ActiveSupport+, -+ActionDispatch+ and so on, it actually defines other functionality. -Such as the +root+, +env+ and +application+ methods which are extremely -useful in Rails 4 applications. +For now, just keep in mind that common functionality like Rails engines, +I18n and Rails configuration is all being defined here. -However, before all that takes place the +rails/ruby_version_check+ file is required first. +h4. Back to +config/environment.rb+ -h4. +railties/lib/rails/ruby_version_check.rb+ - -This file simply checks if the Ruby version is less than 1.9.3 and -raises an error if that is the case. Rails 4 simply will not run on -earlier versions of Ruby. - -NOTE: You should always endeavor to run the latest version of Ruby with your Rails applications. The benefits are many, including security fixes and the like, and very often there is a speed increase associated with it. The caveat is that you could have code that potentially breaks on the latest version, which should be fixed to work on the latest version rather than kept around as an excuse not to upgrade. - -h4. +active_support/core_ext/kernel/reporting.rb+ - -This is the first of the many Active Support core extensions that come with Rails. This one in particular defines methods in the +Kernel+ module which is mixed in to the +Object+ class so the methods are available on +main+ and can therefore be called like this: - -<ruby> -silence_warnings do - # some code -end -</ruby> - -These methods can be used to silence STDERR responses and the +silence_stream+ allows you to also silence other streams. Additionally, this mixin allows you to suppress exceptions and capture streams. For more information see the "Silencing Warnings, Streams, and Exceptions":active_support_core_extensions.html#silencing-warnings-streams-and-exceptions section from the Active Support Core Extensions Guide. - -h4. +active_support/core_ext/array/extract_options.rb+ - -The next file that is required is another Active Support core extension, -this time to the +Array+ and +Hash+ classes. This file defines an -+extract_options!+ method which Rails uses to extract options from -parameters. +When +config/application.rb+ has finished loading Rails, and defined +your application namespace, you go back to +config/environment.rb+, +where your application is initialized. For example, if you application was called ++Blog+, here you would find +Blog::Application.initialize!+, which is +defined in +rails/application.rb+ h4. +railties/lib/rails/application.rb+ -The next file required by +railties/lib/rails.rb+ is +application.rb+. -This file defines the +Rails::Application+ constant which the -application's class defined in +config/application.rb+ in a standard -Rails application depends on. - -Before the +Rails::Application+ class is -defined however, +rails/engine+ is also loaded, which is responsible for -handling the behavior and definitions of Rails engines. - -TIP: You can read more about engines in the "Getting Started with Engines":engines.html guide. - -Among other things, Rails Engine is also responsible for loading the -Railtie class. - -h4. +railties/lib/rails/railtie.rb+ - -The +rails/railtie.rb+ file is responsible for defining +Rails::Railtie+, the underlying class for all ties to Rails now. Gems that want to have their own initializers or rake tasks and hook into Rails should have a +GemName::Railtie+ class that inherits from +Rails::Railtie+. - -The "API documentation":http://api.rubyonrails.org/classes/Rails/Railtie.html for +Rails::Railtie+, much like +Rails::Engine+, explains this class exceptionally well. - -The first require in this file is +rails/initializable.rb+. - -h4. +railties/lib/rails/initializable.rb+ - -Now we reach the end of this particular rabbit hole as +rails/initializable.rb+ doesn't require any more Rails files, only +tsort+ from the Ruby standard library. - -This file defines the +Rails::Initializable+ module which contains the +Initializer+ class, the basis for all initializers in Rails. This module also contains a +ClassMethods+ class which will be included into the +Rails::Railtie+ class when these requires have finished. - -Now that +rails/initializable.rb+ has finished being required from +rails/railtie.rb+, the next require is for +rails/configuration+. - -h4. +railties/lib/rails/configuration.rb+ - -This file defines the +Rails::Configuration+ module, containing the +MiddlewareStackProxy+ class as well as the +Generators+ class. The +MiddlewareStackProxy+ class is used for managing the middleware stack for an application, which we'll see later on. The +Generators+ class provides the functionality used for configuring what generators an application uses through the "+config.generators+ option":configuring.html#configuring-generators. - -The first file required in this file is +activesupport/deprecation+. - -h4. +activesupport/lib/active_support/deprecation.rb+ - -This file, and the files it requires, define the basic deprecation warning features found in Rails. This file is responsible for setting defaults in the +ActiveSupport::Deprecation+ module for the +deprecation_horizon+, +silenced+ and +debug+ values. The files that are required before this happens are: - -* +active_support/deprecation/behaviors+ -* +active_support/deprecation/reporting+ -* +active_support/deprecation/method_wrappers+ -* +active_support/deprecation/proxy_wrappers+ - -h4. +activesupport/lib/active_support/deprecation/behaviors.rb+ - -This file defines the behavior of the +ActiveSupport::Deprecation+ module, setting up the +DEFAULT_BEHAVIORS+ hash constant which contains the three defaults to outputting deprecation warnings: +:stderr+, +:log+ and +:notify+. This file begins by requiring +activesupport/notifications+ and +activesupport/core_ext/array/wrap+. - -h4. +activesupport/lib/active_support/notifications.rb+ - -This file defines the +ActiveSupport::Notifications+ module. Notifications provides an instrumentation API for Ruby, shipping with a queue implementation that consumes and publish events to log subscribers in a thread. - -The "API documentation":http://api.rubyonrails.org/classes/ActiveSupport/Notifications.html for +ActiveSupport::Notifications+ explains the usage of this module, including the methods that it defines. - -The file required in +active_support/notifications.rb+ is +active_support/core_ext/module/delegation+ which is documented in the "Active Support Core Extensions Guide":active_support_core_extensions.html#method-delegation. - -h4. +activesupport/core_ext/array/wrap+ - -As this file comprises of a core extension, it is covered exclusively in "the Active Support Core Extensions guide":active_support_core_extensions.html#wrapping - -h4. +activesupport/lib/active_support/deprecation/reporting.rb+ - -This file is responsible for defining the +warn+ and +silence+ methods for +ActiveSupport::Deprecation+ as well as additional private methods for this module. - -h4. +activesupport/lib/active_support/deprecation/method_wrappers.rb+ - -This file defines a +deprecate_methods+ which is primarily used by the +module/deprecation+ core extension required by the first line of this file. Other core extensions required by this file are the +module/aliasing+ and +array/extract_options+ files. - -h4. +activesupport/lib/active_support/deprecation/proxy_wrappers.rb+ - -+proxy_wrappers.rb+ defines deprecation wrappers for methods, instance variables and constants. Previously, this was used for the +RAILS_ENV+ and +RAILS_ROOT+ constants for 3.0 but since then these constants have been removed. The deprecation message that would be raised from these would be something like: - -<plain> -BadConstant is deprecated! Use GoodConstant instead. -</plain> - -h4. +active_support/ordered_options+ - -This file is the next file required from +rails/configuration.rb+ is the file that defines +ActiveSupport::OrderedOptions+ which is used for configuration options such as +config.active_support+ and the like. - -The next file required is +active_support/core_ext/hash/deep_dup+ which is covered in "Active Support Core Extensions guide":active_support_core_extensions.html#deep_dup - -h4. +active_support/core_ext/object+ - -This file is responsible for requiring many more Active Support core extensions: +The +initialize!+ method looks like this: <ruby> -require 'active_support/core_ext/object/acts_like' -require 'active_support/core_ext/object/blank' -require 'active_support/core_ext/object/duplicable' -require 'active_support/core_ext/object/deep_dup' -require 'active_support/core_ext/object/try' -require 'active_support/core_ext/object/inclusion' - -require 'active_support/core_ext/object/conversions' -require 'active_support/core_ext/object/instance_variables' - -require 'active_support/core_ext/object/to_json' -require 'active_support/core_ext/object/to_param' -require 'active_support/core_ext/object/to_query' -require 'active_support/core_ext/object/with_options' -</ruby> - -The Rails API documentation covers them in great detail, so we're not going to explain each of them. - -The file that is required next from +rails/configuration+ is +rails/paths+. - -h4. +railties/lib/rails/paths.rb+ - -This file defines the +Rails::Paths+ module which allows paths to be configured for a Rails application or engine. Later on in this guide when we cover Rails configuration during the initialization process we'll see this used to set up some default paths for Rails and some of them will be configured to be eager loaded. - -h4. +railties/lib/rails/rack.rb+ - -The final file to be loaded by +railties/lib/rails/configuration.rb+ is +rails/rack+ which defines some simple autoloads: - -<ruby> -module Rails - module Rack - autoload :Debugger, "rails/rack/debugger" - autoload :Logger, "rails/rack/logger" - autoload :LogTailer, "rails/rack/log_tailer" - end +def initialize!(group=:default) #:nodoc: + raise "Application has been already initialized." if @initialized + run_initializers(group, self) + @initialized = true + self end </ruby> -Once this file is finished loading, then the +Rails::Configuration+ class is initialized. This completes the loading of +railties/lib/rails/configuration.rb+ and now we jump back to the loading of +railties/lib/rails/railtie.rb+, where the next file loaded is +active_support/inflector+. - -h4. +activesupport/lib/active_support/inflector.rb+ - -+active_support/inflector.rb+ requires a series of file which are responsible for setting up the basics for knowing how to pluralize and singularize words. These files are: - -<ruby> -require 'active_support/inflector/inflections' -require 'active_support/inflector/transliterate' -require 'active_support/inflector/methods' - -require 'active_support/inflections' -require 'active_support/core_ext/string/inflections' -</ruby> - -The +active_support/inflector/methods+ file has already been required by +active_support/autoload+ and so won't be loaded again here. The +activesupport/lib/active_support/inflector/inflections.rb+ is required by +active_support/inflector/methods+. - -h4. +active_support/inflections+ - -This file references the +ActiveSupport::Inflector+ constant which isn't loaded by this point. But there were autoloads set up in +activesupport/lib/active_support.rb+ which will load the file which loads this constant and so then it will be defined. Then this file defines pluralization and singularization rules for words in Rails. This is how Rails knows how to pluralize "tomato" to "tomatoes". - -<ruby> -inflect.irregular('zombie', 'zombies') -</ruby> - -h4. +activesupport/lib/active_support/inflector/transliterate.rb+ - -This is the file that defines the "+transliterate+":http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html#method-i-transliterate and "+parameterize+":http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html#method-i-parameterize methods. - -h4. +active_support/core_ext/module/introspection+ - -The next file loaded by +rails/railtie+ is the introspection core -extension, which extends +Module+ with methods like +parent_name+, +parent+ and -+parents+. - -h4. +active_support/core_ext/module/delegation+ - -The final file loaded by +rails/railtie+ is the delegation core extension, which defines the "+delegate+":http://api.rubyonrails.org/classes/Module.html#method-i-delegate method. - -h4. Back to +railties/lib/rails/railtie.rb+ - -Once the inflector files have been loaded, the +Rails::Railtie+ class is defined. This class includes a module called +Initializable+, which is actually +Rails::Initializable+. This module includes the +initializer+ method which is used later on for setting up initializers, amongst other methods. - -h4. +railties/lib/rails/initializable.rb+ - -When the module from this file (+Rails::Initializable+) is included, it extends the class it's included into with the +ClassMethods+ module inside of it. This module defines the +initializer+ method which is used to define initializers throughout all of the railties. This file completes the loading of +railties/lib/rails/railtie.rb+. Now we go back to +rails/engine.rb+. - -h4. +railties/lib/rails/engine.rb+ - -The next file required in +rails/engine.rb+ is +active_support/core_ext/module/delegation+ which is documented in the "Active Support Core Extensions Guide":active_support_core_extensions.html#method-delegation. - -The next two files after this are Ruby standard library files: +pathname+ and +rbconfig+. The file after these is +rails/engine/railties+. - -h4. +railties/lib/rails/engine/railties.rb+ - -This file defines the +Rails::Engine::Railties+ class which provides the +engines+ and +railties+ methods which are used later on for defining rake tasks and other functionality for engines and railties. - -h4. Back to +railties/lib/rails/engine.rb+ - -Once +rails/engine/railties.rb+ has finished loading the +Rails::Engine+ class gets its basic functionality defined, such as the +inherited+ method which will be called when this class is inherited from. - -Once this file has finished loading we jump back to +railties/lib/rails/plugin.rb+ - -h4. Back to +railties/lib/rails/plugin.rb+ - -The next file required in this is a core extension from Active Support called +array/conversions+ which is covered in "this section":active_support_core_extensions.html#array-conversions of the Active Support Core Extensions Guide. - -Once that file has finished loading, the +Rails::Plugin+ class is defined. +As you can see, you can only initialize an app once. This is also where the initializers are run. -h4. Back to +railties/lib/rails/application.rb+ +TODO: review this -Jumping back to +rails/application.rb+ now. This file defines the +Rails::Application+ class where the application's class inherits from. This class (and its superclasses) define the basic behaviour on the application's constant such as the +config+ method used for configuring the application. - -Once this file's done then we go back to the +railties/lib/rails.rb+ file, which next requires +rails/version+. - -h4. +railties/lib/rails/version.rb+ - -Much like +active_support/version+, this file defines the +VERSION+ constant which has a +STRING+ constant on it which returns the current version of Rails. - -Once this file has finished loading we go back to +railties/lib/rails.rb+ which then requires +active_support/railtie.rb+. - -h4. +activesupport/lib/active_support/railtie.rb+ - -This file requires +active_support+ and +rails+ which have already been required so these two lines are effectively ignored. The third require in this file is to +active_support/i18n_railtie.rb+. - -h4. +activesupport/lib/active_support/i18n_railtie.rb+ - -This file is the first file that sets up configuration with these lines inside the class: - -<ruby> -class Railtie < Rails::Railtie - config.i18n = ActiveSupport::OrderedOptions.new - config.i18n.railties_load_path = [] - config.i18n.load_path = [] - config.i18n.fallbacks = ActiveSupport::OrderedOptions.new -</ruby> - -By inheriting from +Rails::Railtie+ the +Rails::Railtie#inherited+ method is called: - -<ruby> -def inherited(base) - unless base.abstract_railtie? - base.send(:include, Railtie::Configurable) - subclasses << base - end -end -</ruby> - -This first checks if the Railtie that's inheriting it is a component of Rails itself: - -<ruby> -ABSTRACT_RAILTIES = %w(Rails::Railtie Rails::Plugin Rails::Engine Rails::Application) - -... - -def abstract_railtie? - ABSTRACT_RAILTIES.include?(name) -end -</ruby> - -Because +I18n::Railtie+ isn't in this list, +abstract_railtie?+ returns +false+. Therefore the +Railtie::Configurable+ module is included into this class and the +subclasses+ method is called and +I18n::Railtie+ is added to this new array. - -<ruby> -def subclasses - @subclasses ||= [] -end -</ruby> - -The +config+ method used at the top of +I18n::Railtie+ is defined on +Rails::Railtie+ and is defined like this: - -<ruby> -def config - @config ||= Railtie::Configuration.new -end -</ruby> - -At this point, that +Railtie::Configuration+ constant is automatically loaded which causes the +rails/railties/configuration+ file to be loaded. The line for this is this particular line in +railties/lib/rails/railtie.rb+: - -<ruby> -autoload :Configuration, "rails/railtie/configuration" -</ruby> +The initializers code itself is tricky. What Rails is doing here is it +traverses all the class ancestors looking for an +initializers+ method, +sorting them and running them. For example, the +Engine+ class will make +all the engines available by providing the +initializers+ method. -h4. +railties/lib/rails/railtie/configuration.rb+ +After this is done we go back to +Rack::Server+ -This file begins with a require out to +rails/configuration+ which has already been required earlier in the process and so isn't required again. +h4. Rack: lib/rack/server.rb -This file defines the +Rails::Railtie::Configuration+ class which is responsible for providing a way to easily configure railties and it's the +initialize+ method here which is called by the +config+ method back in the +i18n_railtie.rb+ file. The methods on this object don't exist, and so are rescued by the +method_missing+ defined further down in +configuration.rb+: +Last time we left when the +app+ method was being defined: <ruby> -def method_missing(name, *args, &blk) - if name.to_s =~ /=$/ - @@options[$`.to_sym] = args.first - elsif @@options.key?(name) - @@options[name] - else - super - end -end -</ruby> - -So therefore when an option is referred to it simply stores the value as the key if it's used in a setter context, or retrieves it if used in a getter context. Nothing fancy going on there. - -h4. Back to +activesupport/lib/active_support/i18n_railtie.rb+ - -After the configuration method the +reloader+ method is defined, and then the first of of Railties' initializers is defined: +i18n.callbacks+. +def app + @app ||= begin + if !::File.exist? options[:config] + abort "configuration #{options[:config]} not found" + end -<ruby> -initializer "i18n.callbacks" do - ActionDispatch::Reloader.to_prepare do - I18n::Railtie.reloader.execute_if_updated + app, options = Rack::Builder.parse_file(self.options[:config], opt_parser) + self.options.merge! options + app end end </ruby> -The +initializer+ method (from the +Rails::Initializable+ module) here doesn't run the block, but rather stores it to be run later on: +At this point +app+ is the Rails app itself (a middleware), and what +happens next is Rack will call all the provided middlewares: <ruby> -def initializer(name, opts = {}, &blk) - raise ArgumentError, "A block must be passed when defining an initializer" unless blk - opts[:after] ||= initializers.last.name unless initializers.empty? || initializers.find { |i| i.name == opts[:before] } - initializers << Initializer.new(name, nil, opts, &blk) -end -</ruby> - -An initializer can be configured to run before or after another initializer, which we'll see a couple of times throughout this initialization process. Anything that inherits from +Rails::Railtie+ may also make use of the +initializer+ method, something which is covered in the "Configuration guide":configuring.html#rails-railtie-initializer. - -The +Initializer+ class here is defined within the +Rails::Initializable+ module and its +initialize+ method is defined to just set up a couple of variables: - -<ruby> -def initialize(name, context, options, &block) - @name, @context, @options, @block = name, context, options, block -end -</ruby> - -Once this +initialize+ method is finished, the object is added to the object the +initializers+ method returns: - -<ruby> -def initializers - @initializers ||= self.class.initializers_for(self) -end -</ruby> - -If +@initializers+ isn't set (which it won't be at this point), the +intializers_for+ method will be called for this class. - -<ruby> -def initializers_for(binding) - Collection.new(initializers_chain.map { |i| i.bind(binding) }) -end -</ruby> - -The +Collection+ class in +railties/lib/rails/initializable.rb+ inherits from +Array+ and includes the +TSort+ module which is used to sort out the order of the initializers based on the order they are placed in. - -The +initializers_chain+ method referenced in the +initializers_for+ method is defined like this: - -<ruby> -def initializers_chain - initializers = Collection.new - ancestors.reverse_each do |klass| - next unless klass.respond_to?(:initializers) - initializers = initializers + klass.initializers +def build_app(app) + middleware[options[:environment]].reverse_each do |middleware| + middleware = middleware.call(self) if middleware.respond_to?(:call) + next unless middleware + klass = middleware.shift + app = klass.new(app, *middleware) end - initializers + app end </ruby> -This method collects the initializers from the ancestors of this class and adds them to a new +Collection+ object using the <tt>+</tt> method which is defined like this for the <tt>Collection</tt> class: +Remember, +build_app+ was called (by wrapped_app) in the last line of +Server#start+. +Here's how it looked like when we left: <ruby> -def +(other) - Collection.new(to_a + other.to_a) -end +server.run wrapped_app, options, &blk </ruby> -So this <tt>+</tt> method is overridden to return a new collection comprising of the existing collection as an array and then using the <tt>Array#+</tt> method combines these two collections, returning a "super" +Collection+ object. In this case, the only initializer that's going to be in this new +Collection+ object is the +i18n.callbacks+ initializer. - -The next method to be called after this +initializer+ method is the +after_initialize+ method on the +config+ object, which is defined like this: - -<ruby> -def after_initialize(&block) - ActiveSupport.on_load(:after_initialize, :yield => true, &block) -end -</ruby> - -The +on_load+ method here is provided by the +active_support/lazy_load_hooks+ file which was required earlier and is defined like this: +At this point, the implementation of +server.run+ will depend on the +server you're using. For example, if you were using Mongrel, here's what +the +run+ method would look like: <ruby> -def self.on_load(name, options = {}, &block) - if base = @loaded[name] - execute_hook(base, options, block) +def self.run(app, options={}) + server = ::Mongrel::HttpServer.new( + options[:Host] || '0.0.0.0', + options[:Port] || 8080, + options[:num_processors] || 950, + options[:throttle] || 0, + options[:timeout] || 60) + # Acts like Rack::URLMap, utilizing Mongrel's own path finding methods. + # Use is similar to #run, replacing the app argument with a hash of + # { path=>app, ... } or an instance of Rack::URLMap. + if options[:map] + if app.is_a? Hash + app.each do |path, appl| + path = '/'+path unless path[0] == ?/ + server.register(path, Rack::Handler::Mongrel.new(appl)) + end + elsif app.is_a? URLMap + app.instance_variable_get(:@mapping).each do |(host, path, appl)| + next if !host.nil? && !options[:Host].nil? && options[:Host] != host + path = '/'+path unless path[0] == ?/ + server.register(path, Rack::Handler::Mongrel.new(appl)) + end + else + raise ArgumentError, "first argument should be a Hash or URLMap" + end else - @load_hooks[name] << [block, options] - end -end -</ruby> - -The +@loaded+ variable here is a hash containing elements representing the different components of Rails that have been loaded at this stage. Currently, this hash is empty. So the +else+ is executed here, using the +@load_hooks+ variable defined in +active_support/lazy_load_hooks+: - -<ruby> -@load_hooks = Hash.new {|h,k| h[k] = [] } -</ruby> - -This defines a new hash which has keys that default to empty arrays. This saves Rails from having to do something like this instead: - -<ruby> -@load_hooks[name] = [] -@load_hooks[name] << [block, options] -</ruby> - -The value added to this array here consists of the block and options passed to +after_initialize+. - -We'll see these +@load_hooks+ used later on in the initialization process. - -This rest of +i18n_railtie.rb+ defines the protected class methods +include_fallback_modules+, +init_fallbacks+ and +validate_fallbacks+. - -h4. Back to +activesupport/lib/active_support/railtie.rb+ - -This file defines the +ActiveSupport::Railtie+ constant which like the +I18n::Railtie+ constant just defined, inherits from +Rails::Railtie+ meaning the +inherited+ method would be called again here, including +Rails::Configurable+ into this class. This class makes use of +Rails::Railtie+'s +config+ method again, setting up the configuration options for Active Support. - -Then this Railtie sets up three more initializers: - -* +active_support.deprecation_behavior+ -* +active_support.initialize_time_zone+ -* +active_support.set_configs+ - -We will cover what each of these initializers do when they run. - -Once the +active_support/railtie+ file has finished loading the next file required from +railties/lib/rails.rb+ is the +action_dispatch/railtie+. - -h4. +actionpack/lib/action_dispatch/railtie.rb+ - -This file defines the +ActionDispatch::Railtie+ class, but not before requiring +action_dispatch+. - -h4. +actionpack/lib/action_dispatch.rb+ - -This file starts off with the following requires: - -<ruby> -require 'active_support' -require 'active_support/dependencies/autoload' -require 'active_support/core_ext/module/attribute_accessors' -</ruby> - -The following require is to +action_pack+ (+actionpack/lib/action_pack.rb+) which contains a simple require to +action_pack/version+. This file, like other +version.rb+ files before it, defines the +ActionPack::VERSION+ constant: - -<ruby> -module ActionPack - module VERSION #:nodoc: - MAJOR = 4 - MINOR = 0 - TINY = 0 - PRE = "beta" - - STRING = [MAJOR, MINOR, TINY, PRE].compact.join('.') - end -end -</ruby> - -Once +action_pack+ is finished, then +active_model+ is required. - -h4. +activemodel/lib/active_model.rb+ - -This file makes a require to +active_model/version+ which defines the version for Active Model: - -<ruby> -module ActiveModel - module VERSION #:nodoc: - MAJOR = 4 - MINOR = 0 - TINY = 0 - PRE = "beta" - - STRING = [MAJOR, MINOR, TINY, PRE].compact.join('.') + server.register('/', Rack::Handler::Mongrel.new(app)) end + yield server if block_given? + server.run.join end </ruby> -Once the +version.rb+ file is loaded, the +ActiveModel+ module has its autoloaded constants defined as well as a sub-module called +ActiveModel::Serializers+ which has autoloads of its own. When the +ActiveModel+ module is closed the +active_support/i18n+ file is required. - -h4. +activesupport/lib/active_support/i18n.rb+ - -This is where the +i18n+ gem is required and first configured: - -<ruby> -begin - require 'i18n' - require 'active_support/lazy_load_hooks' -rescue LoadError => e - $stderr.puts "You don't have i18n installed in your application. Please add it to your Gemfile and run bundle install" - raise e -end - -I18n.load_path << "#{File.dirname(__FILE__)}/locale/en.yml" -</ruby> - -In effect, the +I18n+ module first defined by +i18n_railtie+ is extended by the +i18n+ gem, rather than the other way around. This has no ill effect. They both work on the same way. - -This is another spot where +active_support/lazy_load_hooks+ is required, but it has already been required so it's not loaded again. - -If +i18n+ cannot be loaded, the user is presented with an error which says that it cannot be loaded and recommends that it's added to the +Gemfile+. However, in a normal Rails application this gem would be loaded. - -Once it has finished loading, the +I18n.load_path+ method is used to add the +activesupport/lib/active_support/locale/en.yml+ file to I18n's load path. When the translations are loaded in the initialization process, this is one of the files where they will be sourced from. - -The loading of this file finishes the loading of +active_model+ and so we go back to +action_dispatch+. - -h4. Back to +actionpack/lib/action_dispatch.rb+ - -The remainder of this file requires the +rack+ file from the Rack gem which defines the +Rack+ module. After +rack+, there's autoloads defined for the +Rack+, +ActionDispatch+, +ActionDispatch::Http+, +ActionDispatch::Session+. A new method called +autoload_under+ is used here, and this simply prefixes the files where the modules are autoloaded from with the path specified. For example here: - -<ruby> -autoload_under 'testing' do - autoload :Assertions -... -</ruby> - -The +Assertions+ module is in the +action_dispatch/testing+ folder rather than simply +action_dispatch+. - -Finally, this file defines a top-level autoload, the +Mime+ constant. - -h4. Back to +actionpack/lib/action_dispatch/railtie.rb+ - -After +action_dispatch+ is required in this file, the +ActionDispatch::Railtie+ class is defined and is yet another class that inherits from +Rails::Railtie+. This class defines some initial configuration option defaults for +config.action_dispatch+ before setting up a single initializer called +action_dispatch.configure+. - -With +action_dispatch/railtie+ now complete, we go back to +railties/lib/rails.rb+. - -h4. Back to +railties/lib/rails.rb+ - -With the Active Support and Action Dispatch railties now both loaded, the rest of this file deals with setting up UTF-8 to be the default encoding for Rails and then finally setting up the +Rails+ module. This module defines useful methods such as +Rails.logger+, +Rails.application+, +Rails.env+, and +Rails.root+. - -h4. Back to +railties/lib/rails/all.rb+ - -Now that +rails.rb+ is required, the remaining railties are loaded next, beginning with +active_record/railtie+. - -h4. +activerecord/lib/active_record/railtie.rb+ - -Before this file gets into the swing of defining the +ActiveRecord::Railtie+ class, there are a couple of files that are required first. The first one of these is +active_record+. - -h4. +activerecord/lib/active_record.rb+ - -This file begins by detecting if the +lib+ directories of +active_support+ and +active_model+ are not in the load path and if they aren't then adds them. As we saw back in +action_dispatch.rb+, these directories are already there. - -The first couple of requires have already been done by other files and so aren't loaded here, but the next one to +arel+ will require the file provided by the Arel gem, which defines the +Arel+ module. - -<ruby> -require 'active_support' -require 'active_model' -require 'arel' -</ruby> - -The file required next is +active_record/version+ which defines the +ActiveRecord::VERSION+ constant: - -<ruby> -module ActiveRecord - module VERSION #:nodoc: - MAJOR = 4 - MINOR = 0 - TINY = 0 - PRE = "beta" - - STRING = [MAJOR, MINOR, TINY, PRE].compact.join('.') - end -end -</ruby> - -Once these requires are finished, the base for the +ActiveRecord+ module is defined along with its autoloads. - -Near the end of the file, we see this line: - -<ruby> -ActiveSupport.on_load(:active_record) do - Arel::Table.engine = self -end -</ruby> - -This will set the engine for +Arel::Table+ to be +ActiveRecord::Base+. - -The file then finishes with this line: - -<ruby> -ActiveSupport.on_load(:i18n) do - I18n.load_path << File.dirname(__FILE__) + '/active_record/locale/en.yml' -end -</ruby> - -This will add the translations from +activerecord/lib/active_record/locale/en.yml+ to the load path for +I18n+, with this file being parsed when all the translations are loaded. - -h4. Back to +activerecord/lib/active_record/railtie.rb+ - -The next two <tt>require</tt>s in this file aren't run because their files are already required, with +rails+ being required by +rails/all+ and +active_model/railtie+ being required from +action_dispatch+. - -<ruby> -require "rails" -require "active_model/railtie" -</ruby> - -The next +require+ in this file is to +action_controller/railtie+. - -h4. +actionpack/lib/action_controller/railtie.rb+ - -This file begins with a couple more requires to files that have already been loaded: - -<ruby> -require "rails" -require "action_controller" -require "action_dispatch/railtie" -</ruby> - -However the require after these is to a file that hasn't yet been loaded, +action_view/railtie+, which begins by requiring +action_view+. - -h4. +actionpack/lib/action_view.rb+ +We won't dig into the server configuration itself, but this is +the last piece of our journey in the Rails initialization process. -+action_view.rb+ +This high level overview will help you understand when your code is +executed and how, and overall become a better Rails developer. If you +still want to know more, the Rails source code itself is probably the +best place to go next. diff --git a/guides/source/kindle/KINDLE.md b/guides/source/kindle/KINDLE.md index a7d9a4e4cf..08937e053e 100644 --- a/guides/source/kindle/KINDLE.md +++ b/guides/source/kindle/KINDLE.md @@ -9,16 +9,16 @@ ## Resources - * [StackOverflow: Kindle Periodical Format](http://stackoverflow.com/questions/5379565/kindle-periodical-format) + * [Stack Overflow: Kindle Periodical Format](http://stackoverflow.com/questions/5379565/kindle-periodical-format) * Example Periodical [.ncx](https://gist.github.com/808c971ed087b839d462) and [.opf](https://gist.github.com/d6349aa8488eca2ee6d0) - * [Kindle Publishing guidelines](http://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf) + * [Kindle Publishing Guidelines](http://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf) * [KindleGen & Kindle Previewer](http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000234621) ## TODO ### Post release - * Integrate generated Kindle document in to published HTML guides + * Integrate generated Kindle document into published HTML guides * Tweak heading styles (most docs use h3/h4/h5, which end up being smaller than the text under it) * Tweak table styles (smaller text? Many of the tables are unusable on a Kindle in portrait mode) * Have the HTML/XML TOC 'drill down' into the TOCs of the individual guides diff --git a/guides/source/kindle/welcome.html.erb b/guides/source/kindle/welcome.html.erb index e30704c4e6..610a71570f 100644 --- a/guides/source/kindle/welcome.html.erb +++ b/guides/source/kindle/welcome.html.erb @@ -2,4 +2,4 @@ <h3>Kindle Edition</h3> -The Kindle Edition of the Rails Guides should be considered a work in progress. Feedback is really welcome, please see the "Feedback" section at the end of each guide for instructions. +The Kindle Edition of the Rails Guides should be considered a work in progress. Feedback is really welcome. Please see the "Feedback" section at the end of each guide for instructions. diff --git a/guides/source/layouts_and_rendering.textile b/guides/source/layouts_and_rendering.textile index b0a87a5981..32ceecea18 100644 --- a/guides/source/layouts_and_rendering.textile +++ b/guides/source/layouts_and_rendering.textile @@ -23,8 +23,6 @@ From the controller's point of view, there are three ways to create an HTTP resp * Call +redirect_to+ to send an HTTP redirect status code to the browser * Call +head+ to create a response consisting solely of HTTP headers to send back to the browser -I'll cover each of these methods in turn. But first, a few words about the very easiest thing that the controller can do to create a response: nothing at all. - h4. Rendering by Default: Convention Over Configuration in Action You've heard that Rails promotes "convention over configuration". Default rendering is an excellent example of this. By default, controllers in Rails automatically render views with names that correspond to valid routes. For example, if you have this code in your +BooksController+ class: @@ -80,7 +78,7 @@ If we want to display the properties of all the books in our view, we can do so <td><%= book.content %></td> <td><%= link_to "Show", book %></td> <td><%= link_to "Edit", edit_book_path(book) %></td> - <td><%= link_to "Remove", book, :confirm => "Are you sure?", :method => :delete %></td> + <td><%= link_to "Remove", book, :method => :delete, :data => { :confirm => "Are you sure?" } %></td> </tr> <% end %> </table> diff --git a/guides/source/migrations.textile b/guides/source/migrations.textile index 342b5a4d57..06e85e5914 100644 --- a/guides/source/migrations.textile +++ b/guides/source/migrations.textile @@ -111,6 +111,7 @@ Active Record provides methods that perform common data definition tasks in a database independent way (you'll read about them in detail later): * +add_column+ +* +add_reference+ * +add_index+ * +change_column+ * +change_table+ @@ -120,6 +121,7 @@ database independent way (you'll read about them in detail later): * +remove_column+ * +remove_index+ * +rename_column+ +* +remove_reference+ If you need to perform tasks specific to your database (for example create a "foreign key":#active-record-and-referential-integrity constraint) then the @@ -332,6 +334,51 @@ NOTE: The generated migration file for destructive migrations will still be old-style using the +up+ and +down+ methods. This is because Rails needs to know the original data types defined when you made the original changes. +Also the generator accepts column type as +references+(also available as +belongs_to+), for instance + +<shell> +$ rails generate migration AddUserRefToProducts user:references +</shell> + +generates + +<ruby> +class AddUserRefToProducts < ActiveRecord::Migration + def change + add_reference :products, :user, :index => true + end +end +</ruby> + +This migration will create a user_id column and appropriate index. + +h4. Supported type modifiers + +You can also specify some options just after the field type between curly braces. You can use the +following modifiers: + +* +limit+ Sets the maximum size of the +string/text/binary/integer+ fields +* +precision+ Defines the precision for the +decimal+ fields +* +scale+ Defines the scale for the +decimal+ fields +* +polymorphic+ Adds a +type+ column for +belongs_to+ associations + +For instance running + +<shell> +$ rails generate migration AddDetailsToProducts price:decimal{5,2} supplier:references{polymorphic} +</shell> + +will produce a migration that looks like this + +<ruby> +class AddDetailsToProducts < ActiveRecord::Migration + def change + add_column :products, :price, :precision => 5, :scale => 2 + add_reference :products, :user, :polymorphic => true, :index => true + end +end +</ruby> + h3. Writing a Migration Once you have created your migration using one of the generators it's time to diff --git a/guides/source/performance_testing.textile b/guides/source/performance_testing.textile index 958b13cd9e..6c5676c346 100644 --- a/guides/source/performance_testing.textile +++ b/guides/source/performance_testing.textile @@ -1,40 +1,55 @@ h2. Performance Testing Rails Applications -This guide covers the various ways of performance testing a Ruby on Rails application. By referring to this guide, you will be able to: - -* Understand the various types of benchmarking and profiling metrics -* Generate performance and benchmarking tests -* Install and use a GC-patched Ruby binary to measure memory usage and object allocation -* Understand the benchmarking information provided by Rails inside the log files -* Learn about various tools facilitating benchmarking and profiling - -Performance testing is an integral part of the development cycle. It is very important that you don't make your end users wait for too long before the page is completely loaded. Ensuring a pleasant browsing experience for end users and cutting the cost of unnecessary hardware is important for any non-trivial web application. +This guide covers the various ways of performance testing a Ruby on Rails +application. By referring to this guide, you will be able to: + +* Understand the various types of benchmarking and profiling metrics. +* Generate performance and benchmarking tests. +* Install and use a GC-patched Ruby binary to measure memory usage and object + allocation. +* Understand the benchmarking information provided by Rails inside the log files. +* Learn about various tools facilitating benchmarking and profiling. + +Performance testing is an integral part of the development cycle. It is very +important that you don't make your end users wait for too long before the page +is completely loaded. Ensuring a pleasant browsing experience for end users and +cutting the cost of unnecessary hardware is important for any non-trivial web +application. endprologue. h3. Performance Test Cases -Rails performance tests are a special type of integration tests, designed for benchmarking and profiling the test code. With performance tests, you can determine where your application's memory or speed problems are coming from, and get a more in-depth picture of those problems. +Rails performance tests are a special type of integration tests, designed for +benchmarking and profiling the test code. With performance tests, you can +determine where your application's memory or speed problems are coming from, +and get a more in-depth picture of those problems. -In a freshly generated Rails application, +test/performance/browsing_test.rb+ contains an example of a performance test: +In a freshly generated Rails application, +test/performance/browsing_test.rb+ +contains an example of a performance test: <ruby> require 'test_helper' require 'rails/performance_test_help' -# Profiling results for each test method are written to tmp/performance. class BrowsingTest < ActionDispatch::PerformanceTest - def test_homepage + # Refer to the documentation for all available options + # self.profile_options = { runs: 5, metrics: [:wall_time, :memory], + # output: 'tmp/performance', formats: [:flat] } + + test "homepage" do get '/' end end </ruby> -This example is a simple performance test case for profiling a GET request to the application's homepage. +This example is a simple performance test case for profiling a GET request to +the application's homepage. h4. Generating Performance Tests -Rails provides a generator called +performance_test+ for creating new performance tests: +Rails provides a generator called +performance_test+ for creating new +performance tests: <shell> $ rails generate performance_test homepage @@ -47,8 +62,11 @@ require 'test_helper' require 'rails/performance_test_help' class HomepageTest < ActionDispatch::PerformanceTest - # Replace this with your real tests. - def test_homepage + # Refer to the documentation for all available options + # self.profile_options = { :runs => 5, :metrics => [:wall_time, :memory], + # :output => 'tmp/performance', :formats => [:flat] } + + test "homepage" do get '/' end end @@ -60,7 +78,7 @@ Let's assume your application has the following controller and model: <ruby> # routes.rb -root :to => 'home#index' +root to: 'home#dashboard' resources :posts # home_controller.rb @@ -97,9 +115,11 @@ end h5. Controller Example -Because performance tests are a special kind of integration test, you can use the +get+ and +post+ methods in them. +Because performance tests are a special kind of integration test, you can use +the +get+ and +post+ methods in them. -Here's the performance test for +HomeController#dashboard+ and +PostsController#create+: +Here's the performance test for +HomeController#dashboard+ and ++PostsController#create+: <ruby> require 'test_helper' @@ -111,21 +131,24 @@ class PostPerformanceTest < ActionDispatch::PerformanceTest login_as(:lifo) end - def test_homepage + test "homepage" do get '/dashboard' end - def test_creating_new_post - post '/posts', :post => { :body => 'lifo is fooling you' } + test "creating new post" do + post '/posts', post: { body: 'lifo is fooling you' } end end </ruby> -You can find more details about the +get+ and +post+ methods in the "Testing Rails Applications":testing.html guide. +You can find more details about the +get+ and +post+ methods in the +"Testing Rails Applications":testing.html guide. h5. Model Example -Even though the performance tests are integration tests and hence closer to the request/response cycle by nature, you can still performance test pure model code. +Even though the performance tests are integration tests and hence closer to +the request/response cycle by nature, you can still performance test pure model +code. Performance test for +Post+ model: @@ -134,11 +157,11 @@ require 'test_helper' require 'rails/performance_test_help' class PostModelTest < ActionDispatch::PerformanceTest - def test_creation - Post.create :body => 'still fooling you', :cost => '100' + test "creation" do + Post.create body: 'still fooling you', cost: '100' end - def test_slow_method + test "slow method" do # Using posts(:awesome) fixture posts(:awesome).slow_method end @@ -151,7 +174,8 @@ Performance tests can be run in two modes: Benchmarking and Profiling. h5. Benchmarking -Benchmarking makes it easy to quickly gather a few metrics about each test run. By default, each test case is run *4 times* in benchmarking mode. +Benchmarking makes it easy to quickly gather a few metrics about each test run. +By default, each test case is run *4 times* in benchmarking mode. To run performance tests in benchmarking mode: @@ -161,7 +185,10 @@ $ rake test:benchmark h5. Profiling -Profiling allows you to make an in-depth analysis of each of your tests by using an external profiler. Depending on your Ruby interpreter, this profiler can be native (Rubinius, JRuby) or not (MRI, which uses RubyProf). By default, each test case is run *once* in profiling mode. +Profiling allows you to make an in-depth analysis of each of your tests by using +an external profiler. Depending on your Ruby interpreter, this profiler can be +native (Rubinius, JRuby) or not (MRI, which uses RubyProf). By default, each +test case is run *once* in profiling mode. To run performance tests in profiling mode: @@ -171,23 +198,33 @@ $ rake test:profile h4. Metrics -Benchmarking and profiling run performance tests and give you multiple metrics. The availability of each metric is determined by the interpreter being used—none of them support all metrics—and by the mode in use. A brief description of each metric and their availability across interpreters/modes is given below. +Benchmarking and profiling run performance tests and give you multiple metrics. +The availability of each metric is determined by the interpreter being used—none +of them support all metrics—and by the mode in use. A brief description of each +metric and their availability across interpreters/modes is given below. h5. Wall Time -Wall time measures the real world time elapsed during the test run. It is affected by any other processes concurrently running on the system. +Wall time measures the real world time elapsed during the test run. It is +affected by any other processes concurrently running on the system. h5. Process Time -Process time measures the time taken by the process. It is unaffected by any other processes running concurrently on the same system. Hence, process time is likely to be constant for any given performance test, irrespective of the machine load. +Process time measures the time taken by the process. It is unaffected by any +other processes running concurrently on the same system. Hence, process time +is likely to be constant for any given performance test, irrespective of the +machine load. h5. CPU Time -Similar to process time, but leverages the more accurate CPU clock counter available on the Pentium and PowerPC platforms. +Similar to process time, but leverages the more accurate CPU clock counter +available on the Pentium and PowerPC platforms. h5. User Time -User time measures the amount of time the CPU spent in user-mode, i.e. within the process. This is not affected by other processes and by the time it possibly spends blocked. +User time measures the amount of time the CPU spent in user-mode, i.e. within +the process. This is not affected by other processes and by the time it possibly +spends blocked. h5. Memory @@ -223,11 +260,13 @@ h6(#profiling_1). Profiling |_.Rubinius | yes | no | no | no | no | no | no | no | |_.JRuby | yes | no | no | no | no | no | no | no | -NOTE: To profile under JRuby you'll need to run +export JRUBY_OPTS="-Xlaunch.inproc=false --profile.api"+ *before* the performance tests. +NOTE: To profile under JRuby you'll need to run +export JRUBY_OPTS="-Xlaunch.inproc=false --profile.api"+ +*before* the performance tests. h4. Understanding the Output -Performance tests generate different outputs inside +tmp/performance+ directory depending on their mode and metric. +Performance tests generate different outputs inside +tmp/performance+ directory +depending on their mode and metric. h5(#output-benchmarking). Benchmarking @@ -248,7 +287,9 @@ BrowsingTest#test_homepage (31 ms warmup) h6. CSV Files -Performance test results are also appended to +.csv+ files inside +tmp/performance+. For example, running the default +BrowsingTest#test_homepage+ will generate following five files: +Performance test results are also appended to +.csv+ files inside +tmp/performance+. +For example, running the default +BrowsingTest#test_homepage+ will generate +following five files: * BrowsingTest#test_homepage_gc_runs.csv * BrowsingTest#test_homepage_gc_time.csv @@ -256,7 +297,9 @@ Performance test results are also appended to +.csv+ files inside +tmp/performan * BrowsingTest#test_homepage_objects.csv * BrowsingTest#test_homepage_wall_time.csv -As the results are appended to these files each time the performance tests are run in benchmarking mode, you can collect data over a period of time. This can be very helpful in analyzing the effects of code changes. +As the results are appended to these files each time the performance tests are +run in benchmarking mode, you can collect data over a period of time. This can +be very helpful in analyzing the effects of code changes. Sample output of +BrowsingTest#test_homepage_wall_time.csv+: @@ -276,7 +319,10 @@ measurement,created_at,app,rails,ruby,platform h5(#output-profiling). Profiling -In profiling mode, performance tests can generate multiple types of outputs. The command line output is always presented but support for the others is dependent on the interpreter in use. A brief description of each type and their availability across interpreters is given below. +In profiling mode, performance tests can generate multiple types of outputs. +The command line output is always presented but support for the others is +dependent on the interpreter in use. A brief description of each type and +their availability across interpreters is given below. h6. Command Line @@ -291,15 +337,18 @@ BrowsingTest#test_homepage (58 ms warmup) h6. Flat -Flat output shows the metric—time, memory, etc—measure in each method. "Check Ruby-Prof documentation for a better explanation":http://ruby-prof.rubyforge.org/files/examples/flat_txt.html. +Flat output shows the metric—time, memory, etc—measure in each method. +"Check Ruby-Prof documentation for a better explanation":http://ruby-prof.rubyforge.org/files/examples/flat_txt.html. h6. Graph -Graph output shows the metric measure in each method, which methods call it and which methods it calls. "Check Ruby-Prof documentation for a better explanation":http://ruby-prof.rubyforge.org/files/examples/graph_txt.html. +Graph output shows the metric measure in each method, which methods call it and +which methods it calls. "Check Ruby-Prof documentation for a better explanation":http://ruby-prof.rubyforge.org/files/examples/graph_txt.html. h6. Tree -Tree output is profiling information in calltree format for use by "kcachegrind":http://kcachegrind.sourceforge.net/html/Home.html and similar tools. +Tree output is profiling information in calltree format for use by "kcachegrind":http://kcachegrind.sourceforge.net/html/Home.html +and similar tools. h6. Output Availability @@ -311,24 +360,24 @@ h6. Output Availability h4. Tuning Test Runs -Test runs can be tuned by setting the +profile_options+ class variable on your test class. +Test runs can be tuned by setting the +profile_options+ class variable on your +test class. <ruby> require 'test_helper' require 'rails/performance_test_help' -# Profiling results for each test method are written to tmp/performance. class BrowsingTest < ActionDispatch::PerformanceTest - self.profile_options = { :runs => 5, - :metrics => [:wall_time, :memory] } + self.profile_options = { runs: 5, metrics: [:wall_time, :memory] } - def test_homepage + test "homepage" get '/' end end </ruby> -In this example, the test would run 5 times and measure wall time and memory. There are a few configurable options: +In this example, the test would run 5 times and measure wall time and memory. +There are a few configurable options: |_.Option |_.Description|_.Default|_.Mode| |+:runs+ |Number of runs.|Benchmarking: 4, Profiling: 1|Both| @@ -346,11 +395,13 @@ Metrics and formats have different defaults depending on the interpreter in use. |/2.JRuby |Benchmarking|+[:wall_time, :user_time, :memory, :gc_runs, :gc_time]+|N/A| |Profiling |+[:wall_time]+|+[:flat, :graph]+| -As you've probably noticed by now, metrics and formats are specified using a symbol array with each name "underscored.":http://api.rubyonrails.org/classes/String.html#method-i-underscore +As you've probably noticed by now, metrics and formats are specified using a +symbol array with each name "underscored.":http://api.rubyonrails.org/classes/String.html#method-i-underscore h4. Performance Test Environment -Performance tests are run in the +test+ environment. But running performance tests will set the following configuration parameters: +Performance tests are run in the +test+ environment. But running performance +tests will set the following configuration parameters: <shell> ActionController::Base.perform_caching = true @@ -358,11 +409,13 @@ ActiveSupport::Dependencies.mechanism = :require Rails.logger.level = ActiveSupport::BufferedLogger::INFO </shell> -As +ActionController::Base.perform_caching+ is set to +true+, performance tests will behave much as they do in the +production+ environment. +As +ActionController::Base.perform_caching+ is set to +true+, performance tests +will behave much as they do in the +production+ environment. h4. Installing GC-Patched MRI -To get the best from Rails' performance tests under MRI, you'll need to build a special Ruby binary with some super powers. +To get the best from Rails' performance tests under MRI, you'll need to build +a special Ruby binary with some super powers. The recommended patches for each MRI version are: @@ -371,13 +424,18 @@ The recommended patches for each MRI version are: |1.8.7|ruby187gc| |1.9.2 and above|gcdata| -All of these can be found on "RVM's _patches_ directory":https://github.com/wayneeseguin/rvm/tree/master/patches/ruby under each specific interpreter version. +All of these can be found on "RVM's _patches_ directory":https://github.com/wayneeseguin/rvm/tree/master/patches/ruby +under each specific interpreter version. -Concerning the installation itself, you can either do this easily by using "RVM":http://rvm.beginrescueend.com or you can build everything from source, which is a little bit harder. +Concerning the installation itself, you can either do this easily by using +"RVM":http://rvm.beginrescueend.com or you can build everything from source, +which is a little bit harder. h5. Install Using RVM -The process of installing a patched Ruby interpreter is very easy if you let RVM do the hard work. All of the following RVM commands will provide you with a patched Ruby interpreter: +The process of installing a patched Ruby interpreter is very easy if you let RVM +do the hard work. All of the following RVM commands will provide you with a +patched Ruby interpreter: <shell> $ rvm install 1.9.2-p180 --patch gcdata @@ -385,7 +443,8 @@ $ rvm install 1.8.7 --patch ruby187gc $ rvm install 1.9.2-p180 --patch ~/Downloads/downloaded_gcdata_patch.patch </shell> -You can even keep your regular interpreter by assigning a name to the patched one: +You can even keep your regular interpreter by assigning a name to the patched +one: <shell> $ rvm install 1.9.2-p180 --patch gcdata --name gcdata @@ -397,7 +456,9 @@ And it's done! You have installed a patched Ruby interpreter. h5. Install From Source -This process is a bit more complicated, but straightforward nonetheless. If you've never compiled a Ruby binary before, follow these steps to build a Ruby binary inside your home directory. +This process is a bit more complicated, but straightforward nonetheless. If +you've never compiled a Ruby binary before, follow these steps to build a +Ruby binary inside your home directory. h6. Download and Extract @@ -417,7 +478,9 @@ $ curl http://github.com/wayneeseguin/rvm/raw/master/patches/ruby/1.8.7/ruby187g h6. Configure and Install -The following will install Ruby in your home directory's +/rubygc+ directory. Make sure to replace +<homedir>+ with a full patch to your actual home directory. +The following will install Ruby in your home directory's +/rubygc+ directory. +Make sure to replace +<homedir>+ with a full patch to your actual home +directory. <shell> $ ./configure --prefix=/<homedir>/rubygc @@ -438,23 +501,22 @@ alias gcrails='~/rubygc/bin/rails' Don't forget to use your aliases from now on. -h6. Install RubyGems (1.8 only!) - -Download "RubyGems":http://rubyforge.org/projects/rubygems and install it from source. Rubygem's README file should have necessary installation instructions. Please note that this step isn't necessary if you've installed Ruby 1.9 and above. - h4. Using Ruby-Prof on MRI and REE -Add Ruby-Prof to your applications' Gemfile if you want to benchmark/profile under MRI or REE: +Add Ruby-Prof to your applications' Gemfile if you want to benchmark/profile +under MRI or REE: <ruby> -gem 'ruby-prof', :git => 'git://github.com/wycats/ruby-prof.git' +gem 'ruby-prof', git: 'git://github.com/wycats/ruby-prof.git' </ruby> Now run +bundle install+ and you're ready to go. h3. Command Line Tools -Writing performance test cases could be an overkill when you are looking for one time tests. Rails ships with two command line tools that enable quick and dirty performance testing: +Writing performance test cases could be an overkill when you are looking for one +time tests. Rails ships with two command line tools that enable quick and dirty +performance testing: h4. +benchmarker+ @@ -498,11 +560,14 @@ Example: $ rails profiler 'Item.all' 'CouchItem.all' --runs 2 --metrics process_time --formats flat </shell> -NOTE: Metrics and formats vary from interpreter to interpreter. Pass +--help+ to each tool to see the defaults for your interpreter. +NOTE: Metrics and formats vary from interpreter to interpreter. Pass +--help+ to +each tool to see the defaults for your interpreter. h3. Helper Methods -Rails provides various helper methods inside Active Record, Action Controller and Action View to measure the time taken by a given piece of code. The method is called +benchmark()+ in all the three components. +Rails provides various helper methods inside Active Record, Action Controller +and Action View to measure the time taken by a given piece of code. The method +is called +benchmark()+ in all the three components. h4. Model @@ -514,32 +579,34 @@ Project.benchmark("Creating project") do end </ruby> -This benchmarks the code enclosed in the +Project.benchmark("Creating project") do...end+ block and prints the result to the log file: +This benchmarks the code enclosed in the +Project.benchmark("Creating project") do...end+ +block and prints the result to the log file: <ruby> Creating project (185.3ms) </ruby> -Please refer to the "API docs":http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001336 for additional options to +benchmark()+ +Please refer to the "API docs":http://api.rubyonrails.org/classes/ActiveSupport/Benchmarkable.html#method-i-benchmark +for additional options to +benchmark()+. h4. Controller -Similarly, you could use this helper method inside "controllers":http://api.rubyonrails.org/classes/ActionController/Benchmarking/ClassMethods.html#M000715 +Similarly, you could use this helper method inside "controllers.":http://api.rubyonrails.org/classes/ActiveSupport/Benchmarkable.html <ruby> def process_projects - self.class.benchmark("Processing projects") do + benchmark("Processing projects") do Project.process(params[:project_ids]) Project.update_cached_projects end end </ruby> -NOTE: +benchmark+ is a class method inside controllers +NOTE: +benchmark+ is a class method inside controllers. h4. View -And in "views":http://api.rubyonrails.org/classes/ActionController/Benchmarking/ClassMethods.html#M000715: +And in "views":http://api.rubyonrails.org/classes/ActiveSupport/Benchmarkable.html: <erb> <% benchmark("Showing projects partial") do %> @@ -549,7 +616,8 @@ And in "views":http://api.rubyonrails.org/classes/ActionController/Benchmarking/ h3. Request Logging -Rails log files contain very useful information about the time taken to serve each request. Here's a typical log file entry: +Rails log files contain very useful information about the time taken to serve +each request. Here's a typical log file entry: <shell> Processing ItemsController#index (for 127.0.0.1 at 2009-01-08 03:06:39) [GET] @@ -564,9 +632,14 @@ For this section, we're only interested in the last line: Completed in 5ms (View: 2, DB: 0) | 200 OK [http://0.0.0.0/items] </shell> -This data is fairly straightforward to understand. Rails uses millisecond(ms) as the metric to measure the time taken. The complete request spent 5 ms inside Rails, out of which 2 ms were spent rendering views and none was spent communication with the database. It's safe to assume that the remaining 3 ms were spent inside the controller. +This data is fairly straightforward to understand. Rails uses millisecond(ms) as +the metric to measure the time taken. The complete request spent 5 ms inside +Rails, out of which 2 ms were spent rendering views and none was spent +communication with the database. It's safe to assume that the remaining 3 ms +were spent inside the controller. -Michael Koziarski has an "interesting blog post":http://www.therailsway.com/2009/1/6/requests-per-second explaining the importance of using milliseconds as the metric. +Michael Koziarski has an "interesting blog post":http://www.therailsway.com/2009/1/6/requests-per-second +explaining the importance of using milliseconds as the metric. h3. Useful Links @@ -576,6 +649,7 @@ h4. Rails Plugins and Gems * "Palmist":http://www.flyingmachinestudios.com/programming/announcing-palmist * "Rails Footnotes":https://github.com/josevalim/rails-footnotes/tree/master * "Query Reviewer":https://github.com/dsboulder/query_reviewer/tree/master +* "MiniProfiler":http://www.miniprofiler.com h4. Generic Tools @@ -587,11 +661,12 @@ h4. Generic Tools h4. Tutorials and Documentation * "ruby-prof API Documentation":http://ruby-prof.rubyforge.org -* "Request Profiling Railscast":http://railscasts.com/episodes/98-request-profiling - Outdated, but useful for understanding call graphs +* "Request Profiling Railscast":http://railscasts.com/episodes/98-request-profiling - Outdated, but useful for understanding call graphs. h3. Commercial Products -Rails has been lucky to have a few companies dedicated to Rails-specific performance tools. A couple of those are: +Rails has been lucky to have a few companies dedicated to Rails-specific +performance tools. A couple of those are: * "New Relic":http://www.newrelic.com * "Scout":http://scoutapp.com diff --git a/guides/source/plugins.textile b/guides/source/plugins.textile index 95e38db483..fbd317f0c2 100644 --- a/guides/source/plugins.textile +++ b/guides/source/plugins.textile @@ -13,7 +13,7 @@ After reading this guide you should be familiar with: This guide describes how to build a test-driven plugin that will: -* Extend core ruby classes like Hash and String +* Extend core Ruby classes like Hash and String * Add methods to ActiveRecord::Base in the tradition of the 'acts_as' plugins * Give you information about where to put generators in your plugin. @@ -28,7 +28,7 @@ h3. Setup _"vendored plugins"_ were available in previous versions of Rails, but they are deprecated in Rails 3.2, and will not be available in the future. -Currently, Rails plugins are built as gems, _gemified plugins_. They can be shared accross +Currently, Rails plugins are built as gems, _gemified plugins_. They can be shared across different rails applications using RubyGems and Bundler if desired. h4. Generate a gemified plugin. @@ -392,7 +392,7 @@ the creation of generators can be found in the "Generators Guide":generators.htm h3. Publishing your Gem Gem plugins currently in development can easily be shared from any Git repository. To share the Yaffle gem with others, simply -commit the code to a Git repository (like Github) and add a line to the Gemfile of the application in question: +commit the code to a Git repository (like GitHub) and add a line to the Gemfile of the application in question: <ruby> gem 'yaffle', :git => 'git://github.com/yaffle_watcher/yaffle.git' @@ -401,7 +401,7 @@ gem 'yaffle', :git => 'git://github.com/yaffle_watcher/yaffle.git' After running +bundle install+, your gem functionality will be available to the application. When the gem is ready to be shared as a formal release, it can be published to "RubyGems":http://www.rubygems.org. -For more information about publishing gems to RubyGems, see: "http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html":http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html +For more information about publishing gems to RubyGems, see: "Creating and Publishing Your First Ruby Gem":http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html h3. RDoc Documentation @@ -414,7 +414,7 @@ The first step is to update the README file with detailed information about how * How to add the functionality to the app (several examples of common use cases) * Warnings, gotchas or tips that might help users and save them time -Once your README is solid, go through and add rdoc comments to all of the methods that developers will use. It's also customary to add '#:nodoc:' comments to those parts of the code that are not included in the public api. +Once your README is solid, go through and add rdoc comments to all of the methods that developers will use. It's also customary to add '#:nodoc:' comments to those parts of the code that are not included in the public API. Once your comments are good to go, navigate to your plugin directory and run: @@ -425,6 +425,6 @@ $ rake rdoc h4. References * "Developing a RubyGem using Bundler":https://github.com/radar/guides/blob/master/gem-development.md -* "Using Gemspecs As Intended":http://yehudakatz.com/2010/04/02/using-gemspecs-as-intended/ +* "Using .gemspecs as Intended":http://yehudakatz.com/2010/04/02/using-gemspecs-as-intended/ * "Gemspec Reference":http://docs.rubygems.org/read/chapter/20 -* "GemPlugins":http://www.mbleigh.com/2008/06/11/gemplugins-a-brief-introduction-to-the-future-of-rails-plugins +* "GemPlugins: A Brief Introduction to the Future of Rails Plugins":http://www.intridea.com/blog/2008/6/11/gemplugins-a-brief-introduction-to-the-future-of-rails-plugins diff --git a/guides/source/rails_on_rack.textile b/guides/source/rails_on_rack.textile index 3a7c392508..63712b22ef 100644 --- a/guides/source/rails_on_rack.textile +++ b/guides/source/rails_on_rack.textile @@ -195,6 +195,23 @@ use Rack::Runtime run Blog::Application.routes </shell> +If you want to remove session related middleware, do the following: + +<ruby> +# config/application.rb +config.middleware.delete "ActionDispatch::Cookies" +config.middleware.delete "ActionDispatch::Session::CookieStore" +config.middleware.delete "ActionDispatch::Flash" +</ruby> + +And to remove browser related middleware, + +<ruby> +# config/application.rb +config.middleware.delete "ActionDispatch::BestStandardsSupport" +config.middleware.delete "Rack::MethodOverride" +</ruby> + h4. Internal Middleware Stack Much of Action Controller's functionality is implemented as Middlewares. The following list explains the purpose of each of them: diff --git a/guides/source/routing.textile b/guides/source/routing.textile index 7941e655bb..bed7d03e06 100644 --- a/guides/source/routing.textile +++ b/guides/source/routing.textile @@ -32,7 +32,13 @@ the request is dispatched to the +patients+ controller's +show+ action with <tt> h4. Generating Paths and URLs from Code -You can also generate paths and URLs. If your application contains this code: +You can also generate paths and URLs. If the route above is modified to be + +<ruby> +get "/patients/:id" => "patients#show", :as => "patient" +</ruby> + +If your application contains this code: <ruby> @patient = Patient.find(17) @@ -267,6 +273,36 @@ The corresponding route helper would be +publisher_magazine_photo_url+, requirin TIP: _Resources should never be nested more than 1 level deep._ +h4. Routing concerns + +Routing Concerns allows you to declare common routes that can be reused inside others resources and routes. + +<ruby> +concern :commentable do + resources :comments +end + +concern :image_attachable do + resources :images, only: :index +end +</ruby> + +These concerns can be used in resources to avoid code duplication and share behavior across routes. + +<ruby> +resources :messages, concerns: :commentable + +resources :posts, concerns: [:commentable, :image_attachable] +</ruby> + +Also you can use them in any place that you want inside the routes, for example in a scope or namespace call: + +<ruby> +namespace :posts do + concerns :commentable +end +</ruby> + h4. Creating Paths and URLs From Objects In addition to using the routing helpers, Rails can also create paths and URLs from an array of parameters. For example, suppose you have this set of routes: @@ -644,6 +680,14 @@ You should put the +root+ route at the top of the file, because it is the most p NOTE: The +root+ route only routes +GET+ requests to the action. +h4. Unicode character routes + +You can specify unicode character routes directly. For example + +<ruby> +match 'こんにちは' => 'welcome#index' +</ruby> + h3. Customizing Resourceful Routes While the default routes and helpers generated by +resources :posts+ will usually serve you well, you may want to customize them in some way. Rails allows you to customize virtually any generic part of the resourceful helpers. @@ -837,24 +881,6 @@ end This will create routing helpers such as +magazine_periodical_ads_url+ and +edit_magazine_periodical_ad_path+. -h3. Breaking Up a Large Route File - -If you have a large route file that you would like to break up into multiple files, you can use the +#draw+ method in your router: - -<ruby> -draw :admin -</ruby> - -Then, create a file called +config/routes/admin.rb+. Name the file the same as the symbol passed to the +draw+ method. You can then use the normal routing DSL inside that file: - -<ruby> -# in config/routes/admin.rb - -namespace :admin do - resources :posts -end -</ruby> - h3. Inspecting and Testing Routes Rails offers facilities for inspecting and testing your routes. diff --git a/guides/source/security.textile b/guides/source/security.textile index 0931dd6393..49e5da6bb7 100644 --- a/guides/source/security.textile +++ b/guides/source/security.textile @@ -588,26 +588,43 @@ h4. Regular Expressions INFO: _A common pitfall in Ruby's regular expressions is to match the string's beginning and end by ^ and $, instead of \A and \z._ -Ruby uses a slightly different approach than many other languages to match the end and the beginning of a string. That is why even many Ruby and Rails books make this wrong. So how is this a security threat? Imagine you have a File model and you validate the file name by a regular expression like this: +Ruby uses a slightly different approach than many other languages to match the end and the beginning of a string. That is why even many Ruby and Rails books make this wrong. So how is this a security threat? Say you wanted to loosely validate a URL field and you used a simple regular expression like this: <ruby> -class File < ActiveRecord::Base - validates :name, :format => /^[\w\.\-\<plus>]<plus>$/ -end + /^https?:\/\/[^\n]+$/i </ruby> -This means, upon saving, the model will validate the file name to consist only of alphanumeric characters, dots, + and -. And the programmer added ^ and $ so that file name will contain these characters from the beginning to the end of the string. However, _(highlight)in Ruby ^ and $ matches the *line* beginning and line end_. And thus a file name like this passes the filter without problems: +This may work fine in some languages. However, _(highlight)in Ruby ^ and $ match the *line* beginning and line end_. And thus a URL like this passes the filter without problems: <plain> -file.txt%0A<script>alert('hello')</script> +javascript:exploit_code();/* +http://hi.com +*/ </plain> -Whereas %0A is a line feed in URL encoding, so Rails automatically converts it to "file.txt\n<script>alert('hello')</script>". This file name passes the filter because the regular expression matches – up to the line end, the rest does not matter. The correct expression should read: +This URL passes the filter because the regular expression matches – the second line, the rest does not matter. Now imagine we had a view that showed the URL like this: + +<ruby> + link_to "Homepage", @user.homepage +</ruby> + +The link looks innocent to visitors, but when it's clicked, it will execute the JavaScript function "exploit_code" or any other JavaScript the attacker provides. + +To fix the regular expression, \A and \z should be used instead of ^ and $, like so: <ruby> -/\A[\w\.\-\<plus>]<plus>\z/ + /\Ahttps?:\/\/[^\n]+\z/i </ruby> +Since this is a frequent mistake, the format validator (validates_format_of) now raises an exception if the provided regular expression starts with ^ or ends with $. If you do need to use ^ and $ instead of \A and \z (which is rare), you can set the :multiline option to true, like so: + +<ruby> + # content should include a line "Meanwhile" anywhere in the string + validates :content, :format => { :with => /^Meanwhile$/, :multiline => true } +</ruby> + +Note that this only protects you against the most common mistake when using the format validator - you always need to keep in mind that ^ and $ match the *line* beginning and line end in Ruby, and not the beginning and end of a string. + h4. Privilege Escalation WARNING: _Changing a single parameter may give the user unauthorized access. Remember that every parameter may be changed, no matter how much you hide or obfuscate it._ @@ -834,7 +851,7 @@ Network traffic is mostly based on the limited Western alphabet, so new characte &#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;> </html> -This example pops up a message box. It will be recognized by the above sanitize() filter, though. A great tool to obfuscate and encode strings, and thus “get to know your enemy”, is the "Hackvertor":http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php. Rails' sanitize() method does a good job to fend off encoding attacks. +This example pops up a message box. It will be recognized by the above sanitize() filter, though. A great tool to obfuscate and encode strings, and thus “get to know your enemy”, is the "Hackvertor":https://hackvertor.co.uk/public. Rails' sanitize() method does a good job to fend off encoding attacks. h5. Examples from the Underground diff --git a/guides/source/testing.textile b/guides/source/testing.textile index d35be6a70e..4faf59fad8 100644 --- a/guides/source/testing.textile +++ b/guides/source/testing.textile @@ -1,62 +1,57 @@ h2. A Guide to Testing Rails Applications -This guide covers built-in mechanisms offered by Rails to test your application. By referring to this guide, you will be able to: +This guide covers built-in mechanisms offered by Rails to test your +application. By referring to this guide, you will be able to: * Understand Rails testing terminology -* Write unit, functional and integration tests for your application +* Write unit, functional, and integration tests for your application * Identify other popular testing approaches and plugins -This guide won't teach you to write a Rails application; it assumes basic familiarity with the Rails way of doing things. - endprologue. h3. Why Write Tests for your Rails Applications? -* Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers. -* By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring. -* Rails tests can also simulate browser requests and thus you can test your application's response without having to test it through your browser. - -h3. Introduction to Testing - -Testing support was woven into the Rails fabric from the beginning. It wasn't an "oh! let's bolt on support for running tests because they're new and cool" epiphany. Just about every Rails application interacts heavily with a database - and, as a result, your tests will need a database to interact with as well. To write efficient tests, you'll need to understand how to set up this database and populate it with sample data. +Rails makes it super easy to write your tests. It starts by producing skeleton test code while you are creating your models and controllers. -h4. The Three Environments +By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring. -Every Rails application you build has 3 sides: a side for production, a side for development, and a side for testing. +Rails tests can also simulate browser requests and thus you can test your application's response without having to test it through your browser. -One place you'll find this distinction is in the +config/database.yml+ file. This YAML configuration file has 3 different sections defining 3 unique database setups: +h3. Introduction to Testing -* production -* development -* test +Testing support was woven into the Rails fabric from the beginning. It wasn't an "oh! let's bolt on support for running tests because they're new and cool" epiphany. Just about every Rails application interacts heavily with a database and, as a result, your tests will need a database to interact with as well. To write efficient tests, you'll need to understand how to set up this database and populate it with sample data. -This allows you to set up and interact with test data without any danger of your tests altering data from your production environment. +h4. The Test Environment -For example, suppose you need to test your new +delete_this_user_and_every_everything_associated_with_it+ function. Wouldn't you want to run this in an environment where it makes no difference if you destroy data or not? +By default, every Rails application has three environments: development, test, and production. The database for each one of them is configured in +config/database.yml+. -When you do end up destroying your testing database (and it will happen, trust me), you can rebuild it from scratch according to the specs defined in the development database. You can do this by running +rake db:test:prepare+. +A dedicated test database allows you to set up and interact with test data in isolation. Tests can mangle test data with confidence, that won't touch the data in the development or production databases. h4. Rails Sets up for Testing from the Word Go Rails creates a +test+ folder for you as soon as you create a Rails project using +rails new+ _application_name_. If you list the contents of this folder then you shall see: <shell> -$ ls -F test/ +$ ls -F test -fixtures/ functional/ integration/ test_helper.rb unit/ +fixtures/ functional/ integration/ performance/ test_helper.rb unit/ </shell> -The +unit+ folder is meant to hold tests for your models, the +functional+ folder is meant to hold tests for your controllers, and the +integration+ folder is meant to hold tests that involve any number of controllers interacting. Fixtures are a way of organizing test data; they reside in the +fixtures+ folder. The +test_helper.rb+ file holds the default configuration for your tests. +The +unit+ directory is meant to hold tests for your models, the +functional+ directory is meant to hold tests for your controllers, the +integration+ directory is meant to hold tests that involve any number of controllers interacting, and the +performance+ directory is meant for performance tests. + +Fixtures are a way of organizing test data; they reside in the +fixtures+ folder. + +The +test_helper.rb+ file holds the default configuration for your tests. h4. The Low-Down on Fixtures For good tests, you'll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures. -h5. What are Fixtures? +h5. What Are Fixtures? -_Fixtures_ is a fancy word for sample data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent and assume a single format: *YAML*. +_Fixtures_ is a fancy word for sample data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent written in YAML. There is one file per model. -You'll find fixtures under your +test/fixtures+ directory. When you run +rails generate model+ to create a new model, fixture stubs will be automatically created and placed in this directory. +You'll find fixtures under your +test/fixtures+ directory. When you run +rails generate model+ to create a new model fixture stubs will be automatically created and placed in this directory. h5. YAML @@ -77,35 +72,20 @@ steve: profession: guy with keyboard </yaml> -Each fixture is given a name followed by an indented list of colon-separated key/value pairs. Records are separated by a blank space. You can place comments in a fixture file by using the # character in the first column. +Each fixture is given a name followed by an indented list of colon-separated key/value pairs. Records are typically separated by a blank space. You can place comments in a fixture file by using the # character in the first column. h5. ERB'in It Up -ERB allows you to embed ruby code within templates. YAML fixture format is pre-processed with ERB when you load fixtures. This allows you to use Ruby to help you generate some sample data. - -<erb> -<% earth_size = 20 %> -mercury: - size: <%= earth_size / 50 %> - brightest_on: <%= 113.days.ago.to_s(:db) %> - -venus: - size: <%= earth_size / 2 %> - brightest_on: <%= 67.days.ago.to_s(:db) %> - -mars: - size: <%= earth_size - 69 %> - brightest_on: <%= 13.days.from_now.to_s(:db) %> -</erb> - -Anything encased within the +ERB allows you to embed Ruby code within templates. The YAML fixture format is pre-processed with ERB when Rails loads fixtures. This allows you to use Ruby to help you generate some sample data. For example, the following code generates a thousand users: <erb> -<% %> +<% 1000.times do |n| %> +user_<%= n %>: + username: <%= "user%03d" % n %> + email: <%= "user%03d@example.com" % n %> +<% end %> </erb> -tag is considered Ruby code. When this fixture is loaded, the +size+ attribute of the three records will be set to 20/50, 20/2, and 20-69 respectively. The +brightest_on+ attribute will also be evaluated and formatted by Rails to be compatible with the database. - h5. Fixtures in Action Rails by default automatically loads all fixtures from the +test/fixtures+ folder for your unit and functional test. Loading involves three steps: @@ -377,12 +357,12 @@ There are a bunch of different types of assertions you can use. Here's the compl |_.Assertion |_.Purpose| |+assert( boolean, [msg] )+ |Ensures that the object/expression is true.| -|+assert_equal( obj1, obj2, [msg] )+ |Ensures that +obj1 == obj2+ is true.| -|+assert_not_equal( obj1, obj2, [msg] )+ |Ensures that +obj1 == obj2+ is false.| -|+assert_same( obj1, obj2, [msg] )+ |Ensures that +obj1.equal?(obj2)+ is true.| -|+assert_not_same( obj1, obj2, [msg] )+ |Ensures that +obj1.equal?(obj2)+ is false.| +|+assert_equal( expected, actual, [msg] )+ |Ensures that +expected == actual+ is true.| +|+assert_not_equal( expected, actual, [msg] )+ |Ensures that +expected != actual+ is true.| +|+assert_same( expected, actual, [msg] )+ |Ensures that +expected.equal?(actual)+ is true.| +|+assert_not_same( expected, actual, [msg] )+ |Ensures that +!expected.equal?(actual)+ is true.| |+assert_nil( obj, [msg] )+ |Ensures that +obj.nil?+ is true.| -|+assert_not_nil( obj, [msg] )+ |Ensures that +obj.nil?+ is false.| +|+assert_not_nil( obj, [msg] )+ |Ensures that +!obj.nil?+ is true.| |+assert_match( regexp, string, [msg] )+ |Ensures that a string matches the regular expression.| |+assert_no_match( regexp, string, [msg] )+ |Ensures that a string doesn't match the regular expression.| |+assert_in_delta( expecting, actual, delta, [msg] )+ |Ensures that the numbers +expecting+ and +actual+ are within +delta+ of each other.| @@ -526,7 +506,7 @@ You also have access to three instance variables in your functional tests: h4. Testing Templates and Layouts -If you want to make sure that the response rendered the correct template and layout, you can use the +assert_template+ +If you want to make sure that the response rendered the correct template and layout, you can use the +assert_template+ method: <ruby> diff --git a/guides/source/upgrading_ruby_on_rails.textile b/guides/source/upgrading_ruby_on_rails.textile index 6cdc6ab289..cdf7306264 100644 --- a/guides/source/upgrading_ruby_on_rails.textile +++ b/guides/source/upgrading_ruby_on_rails.textile @@ -42,6 +42,10 @@ h4(#active_record4_0). Active Record The <tt>delete</tt> method in collection associations can now receive <tt>Fixnum</tt> or <tt>String</tt> arguments as record ids, besides records, pretty much like the <tt>destroy</tt> method does. Previously it raised <tt>ActiveRecord::AssociationTypeMismatch</tt> for such arguments. From Rails 4.0 on <tt>delete</tt> automatically tries to find the records matching the given ids before deleting them. +Rails 4.0 has changed how orders get stacked in +ActiveRecord::Relation+. In previous versions of rails new order was applied after previous defined order. But this is no long true. Check "ActiveRecord Query guide":active_record_querying.html#ordering for more information. + +Rails 4.0 has changed <tt>serialized_attributes</tt> and <tt>_attr_readonly</tt> to class methods only. Now you shouldn't use instance methods, it's deprecated. You must change them, e.g. <tt>self.serialized_attributes</tt> to <tt>self.class.serialized_attributes</tt>. + h4(#active_model4_0). Active Model Rails 4.0 has changed how errors attach with the <tt>ActiveModel::Validations::ConfirmationValidator</tt>. Now when confirmation validations fail the error will be attached to <tt>:#{attribute}_confirmation</tt> instead of <tt>attribute</tt>. @@ -50,6 +54,12 @@ h4(#action_pack4_0). Action Pack Rails 4.0 changed how <tt>assert_generates</tt>, <tt>assert_recognizes</tt>, and <tt>assert_routing</tt> work. Now all these assertions raise <tt>Assertion</tt> instead of <tt>ActionController::RoutingError</tt>. +Rails 4.0 also changed the way unicode character routes are drawn. Now you can draw unicode character routes directly. If you already draw such routes, you must change them, e.g. <tt>get Rack::Utils.escape('こんにちは'), :controller => 'welcome', :action => 'index'</tt> to <tt>get 'こんにちは', :controller => 'welcome', :action => 'index'</tt>. + +h4(#active_support4_0). Active Support + +Rails 4.0 Removed the `j` alias for `ERB::Util#json_escape` since `j` is already used for `ActionView::Helpers::JavaScriptHelper#escape_javascript`. + h4(#helpers_order). Helpers Loading Order The loading order of helpers from more than one directory has changed in Rails 4.0. Previously, helpers from all directories were gathered and then sorted alphabetically. After upgrade to Rails 4.0 helpers will preserve the order of loaded directories and will be sorted alphabetically only within each directory. Unless you explicitly use <tt>helpers_path</tt> parameter, this change will only impact the way of loading helpers from engines. If you rely on the fact that particular helper from engine loads before or after another helper from application or another engine, you should check if correct methods are available after upgrade. If you would like to change order in which engines are loaded, you can use <tt>config.railties_order=</tt> method. |