Switch to 1.9 hash syntax and remove unnecessary punct.

guides/source/caching_with_rails.md

@@ -5,10 +5,10 @@ This guide will teach you what you need to know about avoiding that expensive ro
 
 After reading this guide, you should be able to use and configure:
 
-* Page, action, and fragment caching.
-* Sweepers.
-* Alternative cache stores.
-* Conditional GET support.
+* Page, action, and fragment caching
+* Sweepers
+* Alternative cache stores
+* Conditional GET support
 
 --------------------------------------------------------------------------------
 
@@ -61,7 +61,7 @@ class ProductsController < ActionController
   end
 
   def create
-    expire_page :action => :index
+    expire_page action: :index
   end
 
 end
@@ -82,13 +82,13 @@ location /  {
 You can disable gzipping by setting `:gzip` option to false (for example, if action returns image):
 
 ```ruby
-caches_page :image, :gzip => false
+caches_page :image, gzip: false
 ```
 
 Or, you can set custom gzip compression level (level names are taken from `Zlib` constants):
 
 ```ruby
-caches_page :image, :gzip => :best_speed
+caches_page :image, gzip: :best_speed
 ```
 
 NOTE: Page caching ignores all parameters. For example `/products?page=1` will be written out to the filesystem as `products.html` with no reference to the `page` parameter. Thus, if someone requests `/products?page=2` later, they will get the cached first page. A workaround for this limitation is to include the parameters in the page's path, e.g. `/products/page/1`.
@@ -114,13 +114,13 @@ class ProductsController < ActionController
   end
 
   def create
-    expire_action :action => :index
+    expire_action action: :index
   end
 
 end
 ```
 
-You can also use `:if` (or `:unless`) to pass a Proc that specifies when the action should be cached. Also, you can use `:layout => false` to cache without layout so that dynamic information in the layout such as logged in user info or the number of items in the cart can be left uncached. This feature is available as of Rails 2.2.
+You can also use `:if` (or `:unless`) to pass a Proc that specifies when the action should be cached. Also, you can use `layout: false` to cache without layout so that dynamic information in the layout such as logged in user info or the number of items in the cart can be left uncached. This feature is available as of Rails 2.2.
 
 You can modify the default action cache path by passing a `:cache_path` option. This will be passed directly to `ActionCachePath.path_for`. This is handy for actions with multiple possible routes that should be cached differently. If a block is given, it is called with the current controller instance.
 
@@ -152,14 +152,14 @@ As an example, if you wanted to show all the orders placed on your website in re
 The cache block in our example will bind to the action that called it and is written out to the same place as the Action Cache, which means that if you want to cache multiple fragments per action, you should provide an `action_suffix` to the cache call:
 
 ```html+erb
-<% cache(:action => 'recent', :action_suffix => 'all_products') do %>
+<% cache(action: 'recent', action_suffix: 'all_products') do %>
   All available products:
 ```
 
 and you can expire it using the `expire_fragment` method, like so:
 
 ```ruby
-expire_fragment(:controller => 'products', :action => 'recent', :action_suffix => 'all_products')
+expire_fragment(controller: 'products', action: 'recent', action_suffix: 'all_products')
 ```
 
 If you don't want the cache block to bind to the action that called it, you can also use globally keyed fragments by calling the `cache` method with a key:
@@ -206,7 +206,7 @@ class ProductSweeper < ActionController::Caching::Sweeper
   private
   def expire_cache_for(product)
     # Expire the index page now that we added a new product
-    expire_page(:controller => 'products', :action => 'index')
+    expire_page(controller: 'products', action: 'index')
 
     # Expire a fragment
     expire_fragment('all_available_products')
@@ -217,7 +217,7 @@ end
 You may notice that the actual product gets passed to the sweeper, so if we were caching the edit action for each product, we could add an expire method which specifies the page we want to expire:
 
 ```ruby
-expire_action(:controller => 'products', :action => 'edit', :id => product.id)
+expire_action(controller: 'products', action: 'edit', id: product.id)
 ```
 
 Then we add it to our controller to tell it to call the sweeper when certain actions are called. So, if we wanted to expire the cached content for the list and edit actions when the create action was called, we could do the following:
@@ -265,7 +265,7 @@ class ProductSweeper < ActionController::Caching::Sweeper
   observe Product
 
   def after_create(product)
-    expire_action(:controller => '/products', :action => 'index')
+    expire_action(controller: '/products', action: 'index')
   end
 end
 ```
@@ -340,7 +340,7 @@ There are some common options used by all cache implementations. These can be pa
 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 }
 ```
 
 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.
@@ -394,8 +394,8 @@ In addition to the standard `:expires_in` option, the `write` method on this cac
 These options are passed to the `write` method as Hash options using either camelCase or underscore notation, as in the following examples:
 
 ```ruby
-Rails.cache.write('key', 'value', :time_to_idle => 60.seconds, :timeToLive => 600.seconds)
-caches_action :index, :expires_in => 60.seconds, :unless_exist => true
+Rails.cache.write('key', 'value', time_to_idle: 60.seconds, timeToLive: 600.seconds)
+caches_action :index, expires_in: 60.seconds, unless_exist: true
 ```
 
 For more information about Ehcache, see [http://ehcache.org/](http://ehcache.org/) .
@@ -427,7 +427,7 @@ You can use Hashes and Arrays of values as cache keys.
 
 ```ruby
 # This is a legal cache key
-Rails.cache.read(:site => "mysite", :owners => [owner_1, owner_2])
+Rails.cache.read(site: "mysite", owners: [owner_1, owner_2])
 ```
 
 The keys you use on `Rails.cache` will not be the same as those actually used with the storage engine. They may be modified with a namespace or altered to fit technology backend constraints. This means, for instance, that you can't save values with `Rails.cache` and then try to pull them out with the `memcache-client` gem. However, you also don't need to worry about exceeding the memcached size limit or violating syntax rules.
@@ -449,7 +449,7 @@ class ProductsController < ApplicationController
 
     # If the request is stale according to the given timestamp and etag value
     # (i.e. it needs to be processed again) then execute this block
-    if stale?(:last_modified => @product.updated_at.utc, :etag => @product.cache_key)
+    if stale?(last_modified: @product.updated_at.utc, etag: @product.cache_key)
       respond_to do |wants|
         # ... normal response processing
       end
@@ -484,7 +484,7 @@ class ProductsController < ApplicationController
 
   def show
     @product = Product.find(params[:id])
-    fresh_when :last_modified => @product.published_at.utc, :etag => @product
+    fresh_when last_modified: @product.published_at.utc, etag: @product
   end
 end
 ```