aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--actionpack/lib/action_controller/caching/pages.rb11
-rw-r--r--activerecord/lib/active_record/migration.rb10
-rw-r--r--activesupport/lib/active_support/testing/assertions.rb2
-rw-r--r--railties/guides/source/action_controller_overview.textile2
-rw-r--r--railties/guides/source/active_record_querying.textile54
-rw-r--r--railties/guides/source/asset_pipeline.textile42
6 files changed, 91 insertions, 30 deletions
diff --git a/actionpack/lib/action_controller/caching/pages.rb b/actionpack/lib/action_controller/caching/pages.rb
index 8c583c7ce0..496390402b 100644
--- a/actionpack/lib/action_controller/caching/pages.rb
+++ b/actionpack/lib/action_controller/caching/pages.rb
@@ -16,9 +16,10 @@ module ActionController #:nodoc:
# caches_page :show, :new
# end
#
- # This will generate cache files such as <tt>weblog/show/5.html</tt> and <tt>weblog/new.html</tt>,
- # which match the URLs used to trigger the dynamic generation. This is how the web server is able
- # pick up a cache file when it exists and otherwise let the request pass on to Action Pack to generate it.
+ # This will generate cache files such as <tt>weblog/show/5.html</tt> and <tt>weblog/new.html</tt>, which match the URLs used
+ # that would normally trigger dynamic page generation. Page caching works by configuring a web server to first check for the
+ # existence of files on disk, and to serve them directly when found, without passing the request through to Action Pack.
+ # This is much faster than handling the full dynamic request in the usual way.
#
# Expiration of the cache is handled by deleting the cached file, which results in a lazy regeneration approach where the cache
# is not restored before another hit is made against it. The API for doing so mimics the options from +url_for+ and friends:
@@ -132,8 +133,8 @@ module ActionController #:nodoc:
end
end
- # Manually cache the +content+ in the key determined by +options+. If no content is provided, the contents of response.body is used
- # If no options are provided, the requested url is used. Example:
+ # Manually cache the +content+ in the key determined by +options+. If no content is provided, the contents of response.body is used.
+ # If no options are provided, the url of the current request being handled is used. Example:
# cache_page "I'm the cached content", :controller => "lists", :action => "show"
def cache_page(content = nil, options = nil)
return unless self.class.perform_caching && caching_allowed?
diff --git a/activerecord/lib/active_record/migration.rb b/activerecord/lib/active_record/migration.rb
index 3d1bc5c1e0..c459846264 100644
--- a/activerecord/lib/active_record/migration.rb
+++ b/activerecord/lib/active_record/migration.rb
@@ -66,9 +66,9 @@ module ActiveRecord
# create_table :system_settings do |t|
# t.string :name
# t.string :label
- # t.text :value
+ # t.text :value
# t.string :type
- # t.integer :position
+ # t.integer :position
# end
#
# SystemSetting.create :name => "notice",
@@ -181,7 +181,7 @@ module ActiveRecord
#
# class RemoveEmptyTags < ActiveRecord::Migration
# def up
- # Tag.find(:all).each { |tag| tag.destroy if tag.pages.empty? }
+ # Tag.all.each { |tag| tag.destroy if tag.pages.empty? }
# end
#
# def down
@@ -227,7 +227,7 @@ module ActiveRecord
# def up
# add_column :people, :salary, :integer
# Person.reset_column_information
- # Person.find(:all).each do |p|
+ # Person.all.each do |p|
# p.update_attribute :salary, SalaryCalculator.compute(p)
# end
# end
@@ -247,7 +247,7 @@ module ActiveRecord
# def up
# ...
# say_with_time "Updating salaries..." do
- # Person.find(:all).each do |p|
+ # Person.all.each do |p|
# p.update_attribute :salary, SalaryCalculator.compute(p)
# end
# end
diff --git a/activesupport/lib/active_support/testing/assertions.rb b/activesupport/lib/active_support/testing/assertions.rb
index 05da50e150..3864b1f5a6 100644
--- a/activesupport/lib/active_support/testing/assertions.rb
+++ b/activesupport/lib/active_support/testing/assertions.rb
@@ -68,7 +68,7 @@ module ActiveSupport
#
# A error message can be specified.
#
- # assert_no_difference 'Article.count', "An Article should not be destroyed" do
+ # assert_no_difference 'Article.count', "An Article should not be created" do
# post :create, :article => invalid_attributes
# end
def assert_no_difference(expression, message = nil, &block)
diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index 891bae3d5e..073e3bddcf 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -802,7 +802,7 @@ class DinnerController
end
</ruby>
-Just like the filter, you could also passing +:only+ and +:except+ to enforce the secure connection only to specific actions
+Just like the filter, you could also passing +:only+ and +:except+ to enforce the secure connection only to specific actions.
<ruby>
class DinnerController
diff --git a/railties/guides/source/active_record_querying.textile b/railties/guides/source/active_record_querying.textile
index e3871a3c34..8937a0c172 100644
--- a/railties/guides/source/active_record_querying.textile
+++ b/railties/guides/source/active_record_querying.textile
@@ -466,7 +466,7 @@ To apply a +GROUP BY+ clause to the SQL fired by the finder, you can specify the
For example, if you want to find a collection of the dates orders were created on:
<ruby>
-Order.group("date(created_at)").order("created_at")
+Order.select("date(created_at) as ordered_date, sum(price) as total_price").group("date(created_at)")
</ruby>
And this will give you a single +Order+ object for each date where there are orders in the database.
@@ -474,7 +474,7 @@ 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 * FROM orders GROUP BY date(created_at) ORDER BY created_at
+SELECT date(created_at) as ordered_date, sum(price) as total_price FROM orders GROUP BY date(created_at)
</sql>
h3. Having
@@ -484,16 +484,16 @@ SQL uses the +HAVING+ clause to specify conditions on the +GROUP BY+ fields. You
For example:
<ruby>
-Order.group("date(created_at)").having("created_at < ?", 1.month.ago)
+Order.select("date(created_at) as ordered_date, sum(price) as total_price").group("date(created_at)").having("sum(price) > ?", 100)
</ruby>
The SQL that would be executed would be something like this:
<sql>
-SELECT * FROM orders GROUP BY date(created_at) HAVING created_at < '2011-04-27'
+SELECT date(created_at) as ordered_date, sum(price) as total_price FROM orders GROUP BY date(created_at) HAVING sum(price) > 100
</sql>
-This will return single order objects for each day, but only those that are at least one month old.
+This will return single order objects for each day, but only those that are ordered more than $100 in a day.
h3. Overriding Conditions
@@ -965,6 +965,47 @@ Using a class method is the preferred way to accept arguments for scopes. These
category.posts.1_week_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.
+
+<ruby>
+class Client < ActiveRecord::Base
+ default_scope where("removed_at IS NULL")
+end
+</ruby>
+
+When queries are executed on this model, the SQL query will now look something like this:
+
+<sql>
+SELECT * FROM clients WHERE removed_at IS NULL
+</sql>
+
+h4. Removing all scoping
+
+If we wish to remove scoping for any reason we can use the +unscoped+ method. This is especially useful if a +default_scope+ is specified in the model and should not be applied for this particular query.
+
+<ruby>
+Client.unscoped.all
+</ruby>
+
+This method removes all scoping and will do a normal query on the table.
+
h3. Dynamic Finders
For every field (also known as an attribute) you define in your table, Active Record provides a finder method. If you have a field called +first_name+ on your +Client+ model for example, you get +find_by_first_name+ and +find_all_by_first_name+ for free from Active Record. If you have a +locked+ field on the +Client+ model, you also get +find_by_locked+ and +find_all_by_locked+ methods.
@@ -1146,7 +1187,8 @@ For options, please see the parent section, "Calculations":#calculations.
h3. Changelog
-* December 23 2010: Add documentation for the +scope+ method. "Ryan Bigg":http://ryanbigg.com
+* June 26 2011: Added documentation for the +scoped+, +unscoped+ and +default+ methods. "Ryan Bigg":credits.html#radar
+* December 23 2010: Add documentation for the +scope+ method. "Ryan Bigg":credits.html#radar
* April 7, 2010: Fixed document to validate XHTML 1.0 Strict. "Jaime Iniesta":http://jaimeiniesta.com
* February 3, 2010: Update to Rails 3 by "James Miller":credits.html#bensie
* February 7, 2009: Second version by "Pratik":credits.html#lifo
diff --git a/railties/guides/source/asset_pipeline.textile b/railties/guides/source/asset_pipeline.textile
index de66876623..4bedaa5a71 100644
--- a/railties/guides/source/asset_pipeline.textile
+++ b/railties/guides/source/asset_pipeline.textile
@@ -13,7 +13,9 @@ endprologue.
h3. What Is The Asset Pipeline?
-With Rails 3.1 comes a new feature known as the asset pipeline. The asset pipeline provides features that have usually been implemented by external gems, such as "Jammit":http://documentcloud.github.com/jammit and "Sprockets.":http://getsprockets.org These gems are popular for being able to serve concatenated or compressed versions of the assets of an application, such as Cascade Style Sheets (CSS) or JavaScript (JS) files so that the number of requests made to the server are reduced, making the page load faster. Rails 3.1 includes the Sprockets gem.
+With Rails 3.1 comes a new feature known as the asset pipeline. The asset pipeline provides features that have usually been implemented by external Ruby libraries, such as Jammit and Sprockets. These libraries would serve concatenated or compressed versions of the assets of an application, such as stylesheets or JavaScript files so that the number of requests made to the server are lessened, making the page load faster. Rails 3.1 includes the +sprockets-rails+ gem, which depends on the +sprockets+ gem, by default.
+
+By having this now as a core feature of Rails, all developers can benefit from the power of having their assets pre-processed, compressed and minified by one central library, Sprockets.
h3. How to Use the Asset Pipeline
@@ -21,7 +23,7 @@ In previous versions of Rails, all assets lived under the +public+ directory in
This is not to say that assets can (or should) no longer be placed in +public+. They still can be, they will just be served by the application or the web server which is running the application and served just like normal files. You would only use +app/assets+ if you wish your files to undergo some pre-processing before they are served.
-When a scaffold or controller is generated for the application, Rails will also generate a JavaScript file (or CoffeeScript if the +coffee-script+ gem is in the +Gemfile+) and a Cascade Style Sheet file (or SCSS if +sass-rails+ is in the +Gemfile+) file for that controller. For example, if a +ProjectsController+ is generated, there will be a new file at +app/assets/javascripts/projects.js.coffee+ and another at +app/assets/stylesheets/projects.css.scss+. You should put any JavaScript or CSS unique to a controller inside their respective asset files.
+When a scaffold or controller is generated for the application, Rails will also generate a JavaScript file (or CoffeeScript if the +coffee-script+ gem is in the +Gemfile+) and a Cascading Style Sheet file (or SCSS if +sass-rails+ is in the +Gemfile+) file for that controller. For example, if a +ProjectsController+ is generated, there will be a new file at +app/assets/javascripts/projects.js.coffee+ and another at +app/assets/stylesheets/projects.css.scss+. You should put any JavaScript or CSS unique to a controller inside their respective asset files.
h4. Asset Organization
@@ -35,10 +37,6 @@ Assets can be placed inside an application in one of three locations: +app/asset
Any subdirectory that exists within these three locations will be added to the search path for Sprockets (visible by calling +Rails.application.config.assets.paths+ in a console). When an asset is requested, these paths will be looked through to see if they contain an asset matching the name specified. Once an asset has been found, it's processed by Sprockets and then served up.
-h4. External Assets
-
-Assets can also come from external sources such as engines. A good example of this is the +jquery-rails+ gem which comes with Rails as the standard JavaScript library gem. This gem contains an engine class which inherits from +Rails::Engine+. By doing this, Rails is informed that the directory for this gem may contain assets and the +app/assets+, +lib/assets+ and +vendor/assets+ directories of this engine are added to the search path of Sprockets.
-
h4. Serving Assets
To serve assets, we can use the same tags that we are generally familiar with:
@@ -47,9 +45,16 @@ To serve assets, we can use the same tags that we are generally familiar with:
<%= image_tag "rails.png" %>
</erb>
-Providing that assets are enabled within our application (+config.assets.enabled+ in your environment is set to +true+), this file will be served by Sprockets unless a file at +public/assets/rails.png+ exists, in which case that file will be served. Otherwise, Sprockets will look through the available paths until it finds a file that matches the name and then will serve it, first looking in the application's assets directories and then falling back to the various engines of the application.
+Providing that assets are enabled within our application (+config.assets.enabled+ in your environment is set to +true+), this file will be served by Sprockets unless a file at +public/assets/rails.png+ exists, in which case that file will be served. Alternatively, a file with an MD5 hash after its name such as +public/assets/rails-af27b6a414e6da00003503148be9b409.png+ will also be picked up by Sprockets. How these hashes are generated is covered in the "Production Assets":#production_assets section later on in this guide.
-Sprockets does not add any new methods to require your assets, we still use the familiar +javascript_include_tag+ and +stylesheet_link_tag+. You can use it to include from the normal public directory or the assets directory.
+Otherwise, Sprockets will look through the available paths until it finds a file that matches the name and then will serve it, first looking in the application's assets directories and then falling back to the various engines of the application.
+
+Sprockets does not add any new methods to require your assets, we still use the familiar +javascript_include_tag+ and +stylesheet_link_tag+.
+
+<erb>
+ <%= stylesheet_link_tag "application" %>
+ <%= javascript_include_tag "application" %>
+</erb>
h4. Manifest Files and Directives
@@ -90,17 +95,30 @@ In addition to this single layer of pre-processing, we can also put on additiona
Keep in mind that the order of these pre-processors is important. For example, if we called our JavaScript file +app/assets/javascripts/projects.js.erb.coffee+ then it would be processed with the CoffeeScript interpreter first, which wouldn't understand ERB and therefore we would run into problems.
+h3. Production Assets
+
+In the production environment, assets are served slightly differently to how they are served in the development environment.
+
+TODO: Talk here about:
+ * Rack::Cache's caching
+ * Sprocket's auto-generated MD5 hashes
+ * Sass-rails's handy +image_url+ helpers
+ * ERB pre-processing and +asset_url+
+
+
h4. Compressing Assets
The default Gemfile also includes the "uglifier":https://github.com/lautis/uglifier gem. This gem wraps "UglifierJS":https://github.com/mishoo/UglifyJS (written for NodeJS) in Ruby. It compress your code by removing white spaces and other magical things like changing your if and else statements to ternary operators when possible.
Sprockets also creates a "Gzip":http://en.wikipedia.org/wiki/Gzip (.gz) of your assets. This prevents your server from contently compressing your assets for each request. You must configure your server to use GZip compression and serve the compressed assets in {location}. {Give Apache and NGINX examples since those are what's cool}
-h4. Adding Assets to Your Gems
+h3. Adding Assets to Your Gems
+
+Assets can also come from external sources in the form of gems.
-To include your assets inside of a gem, simple package it in +lib/assets+ as you would in +app/assets+. You should append or prepend the name of your gem though, this should help avoid name conflicts with other gems or the user's application.
+A good example of this is the +jquery-rails+ gem which comes with Rails as the standard JavaScript library gem. This gem contains an engine class which inherits from +Rails::Engine+. By doing this, Rails is informed that the directory for this gem may contain assets and the +app/assets+, +lib/assets+ and +vendor/assets+ directories of this engine are added to the search path of Sprockets.
-h4. Making Your Library or Gem a Pre-Processor
+h3. Making Your Library or Gem a Pre-Processor
"You should be able to register [your gems] on Tilt and Sprockets will find them." - Josh
-Tilt: https://github.com/rtomayko/tilt \ No newline at end of file
+Tilt: https://github.com/rtomayko/tilt