Permalink
Browse files

Merge pull request #367 from kytrinyx/topics-to-19-hashes

Update the `/topics` section to use 1.9-syntax for hashes
  • Loading branch information...
steveklabnik committed Nov 18, 2012
2 parents 99fbbc9 + 8c0c534 commit a10fb501eb9f524b851f5e4e6c33f096bd3fd16d
Showing with 274 additions and 274 deletions.
  1. +1 −1 source/topics/auth/authorization.markdown
  2. +9 −9 source/topics/auth/local_authentication.markdown
  3. +8 −8 source/topics/auth/remote_authentication.markdown
  4. +1 −1 source/topics/better_views/erb_and_haml.markdown
  5. +12 −12 source/topics/better_views/view_partials.markdown
  6. +4 −4 source/topics/capybara/capybara_practice.markdown
  7. +8 −8 source/topics/capybara/capybara_with_rack_test.markdown
  8. +6 −6 source/topics/capybara/capybara_with_selenium_and_webkit.markdown
  9. +1 −1 source/topics/continuous_integration.markdown
  10. +1 −1 source/topics/controller_modules.markdown
  11. +6 −6 source/topics/controllers/filters.markdown
  12. +8 −8 source/topics/controllers/flash.markdown
  13. +4 −4 source/topics/controllers/friendly-urls.markdown
  14. +2 −2 source/topics/controllers/parameters.markdown
  15. +16 −16 source/topics/controllers/render_and_redirect.markdown
  16. +2 −2 source/topics/controllers/sessions_and_conversations.markdown
  17. +4 −4 source/topics/controllers/slimming_controllers.markdown
  18. +3 −3 source/topics/debugging/debugger.markdown
  19. +2 −2 source/topics/debugging/outputting_text.markdown
  20. +12 −12 source/topics/decorators.markdown
  21. +2 −2 source/topics/environment/bundler.markdown
  22. +1 −1 source/topics/environment/heroku.markdown
  23. +7 −7 source/topics/heroku.markdown
  24. +7 −7 source/topics/internal_testing/factories.markdown
  25. +3 −3 source/topics/internal_testing/rspec_and_bdd.markdown
  26. +1 −1 source/topics/internal_testing/rspec_practices.markdown
  27. +6 −6 source/topics/internationalization.markdown
  28. +3 −3 source/topics/javascript/rails_and_javascript.markdown
  29. +2 −2 source/topics/models/legacy_databases.markdown
  30. +9 −9 source/topics/models/modules.markdown
  31. +3 −3 source/topics/models/polymorphism.markdown
  32. +6 −6 source/topics/models/processor_models.markdown
  33. +12 −12 source/topics/models/relationships.markdown
  34. +27 −27 source/topics/models/validations.markdown
  35. +3 −3 source/topics/performance/background_jobs.markdown
  36. +2 −2 source/topics/performance/caching.markdown
  37. +2 −2 source/topics/performance/measuring.markdown
  38. +15 −15 source/topics/performance/queries.markdown
  39. +26 −26 source/topics/routes/router.markdown
  40. +1 −1 source/topics/search.markdown
  41. +3 −3 source/topics/systems/automation.markdown
  42. +6 −6 source/topics/web_services/active_resource.markdown
  43. +9 −9 source/topics/web_services/api.markdown
  44. +8 −8 source/topics/web_services/encoding_and_filtering.markdown
@@ -173,7 +173,7 @@ class ApplicationController < ActionController::Base
# Catch all CanCan errors and alert the user of the exception
rescue_from CanCan::AccessDenied do | exception |
- redirect_to root_url, :alert => exception.message
+ redirect_to root_url, alert: exception.message
end
end
@@ -56,7 +56,7 @@ To enable the `confirmable` feature:
1. add `:confirmable` to the list of options following `devise` in `app/models/user.rb`
2. uncomment the `t.confirmable` line in the migration
-3. uncomment the `t.add_index :users, :confirmation_token, :unique => true` line in the migration
+3. uncomment the `t.add_index :users, :confirmation_token, unique: true` line in the migration
After the desired configuration changes have been made it's time to `rake db:migrate` the database and create the new `users` table.
@@ -71,7 +71,7 @@ The instructions displayed with the `devise:install` generator mentioned specify
If we want users to go to `/articles` after signing in then we'd add the following route:
```ruby
-root :to => 'articles#index'
+root to: 'articles#index'
```
## Using Authentication
@@ -109,7 +109,7 @@ It's more likely that we only want to force authentication for a few actions in
We can allow unauthenticated access to the index and show actions, while still restricting the rest, by making the following change to `articles_controller.rb`:
```ruby
-before_filter :authenticate_user!, :except => [:show, :index]
+before_filter :authenticate_user!, except: [:show, :index]
```
Here we tell devise to only authenticate against actions other than `show` and `index`. Now, users that haven't signed in can still read the articles.
@@ -131,7 +131,7 @@ In our layout, let's add a header for users to sign out if they are signed in, o
<div id="account">
<% if current_user %>
<span>Welcome, <%= current_user.email %></span>
- <%= link_to "Sign out", destroy_user_session_path, :method => :delete %>
+ <%= link_to "Sign out", destroy_user_session_path, method: :delete %>
<% else %>
<%= link_to "Sign in", new_user_session_path %>
<% end %>
@@ -147,7 +147,7 @@ The most important setting is `default_url_options` so that links contained in e
```ruby
# config/environments/development.rb
#...
-config.action_mailer.default_url_options = { :host => 'localhost:3000' }
+config.action_mailer.default_url_options = { host: 'localhost:3000' }
#...
```
@@ -270,9 +270,9 @@ This will allow a new user to be created without specifying a password, so the f
Next, alter the devise route in `config/routes.rb` to override the controller that is used for confirming a user's account:
```ruby
-devise_for :users, :controllers => { :confirmations => "confirmations" } do
- put "confirm_user", :to => "confirmations#confirm_user"
- get "confirmation", :to => "confirmations#show"
+devise_for :users, controllers: { confirmations: "confirmations" } do
+ put "confirm_user", to: "confirmations#confirm_user"
+ get "confirmation", to: "confirmations#show"
end
```
@@ -298,7 +298,7 @@ Now we need a view for `"confirmations#show"`. Here's `app/views/confirmations/
```erb
<h2>Set Password for <%= @user.email %></h2>
-<%= form_for(@user, :as => resource_name, :url => confirm_user_path) do |f| %>
+<%= form_for(@user, as: resource_name, url: confirm_user_path) do |f| %>
<%= devise_error_messages! %>
<%= f.hidden_field :confirmation_token %>
@@ -73,7 +73,7 @@ The authentication pattern starts with your app redirecting to the third party a
You'd handle that callback by adding a route in `/config/routes.rb`:
```ruby
-match '/auth/:provider/callback', :to => 'sessions#create'
+match '/auth/:provider/callback', to: 'sessions#create'
```
Your router will attempt to call the `create` action of the `SessionsController` when the callback is triggered.
@@ -85,7 +85,7 @@ You can generate a controller at the command line and add a create method like t
```ruby
class SessionsController < ApplicationController
def create
- render :text => debug request.env["omniauth.auth"]
+ render text: debug request.env["omniauth.auth"]
end
end
```
@@ -147,7 +147,7 @@ Now, back to `SessionsController`, we need to save the logged in user's id in th
def create
@user = User.find_or_create_by_auth(request.env["omniauth.auth"])
session[:user_id] = @user.id
- redirect_to articles_path, :notice => "Logged in as #{@user.name}"
+ redirect_to articles_path, notice: "Logged in as #{@user.name}"
end
```
@@ -163,9 +163,9 @@ Open `/app/views/layouts/application.html.erb` and you'll see the framing for al
<div id="account">
<% if current_user %>
<span>Welcome, <%= current_user.name %></span>
- <%= link_to "logout", logout_path, :id => "login" %>
+ <%= link_to "logout", logout_path, id: "login" %>
<% else %>
- <%= link_to "login", login_path, :id => "logout" %>
+ <%= link_to "login", login_path, id: "logout" %>
<% end %>
</div>
```
@@ -212,8 +212,8 @@ Just because we're following the REST convention doesn't mean we can't also crea
Open `/config/routes.rb` and add two custom routes:
```ruby
- match "/login" => redirect("/auth/twitter"), :as => :login
- match "/logout" => "sessions#destroy", :as => :logout
+ match "/login" => redirect("/auth/twitter"), as: :login
+ match "/logout" => "sessions#destroy", as: :logout
```
The first line creates a path named `login` which redirects to the static address `/auth/twitter` which will be intercepted by the OmniAuth middleware. The second line creates a `logout` path which will call the `destroy` action of our `SessionsController`.
@@ -236,7 +236,7 @@ Our login works great, but we can't logout! When you click the logout link it's
* Define a `root_path` in your router like this:
```ruby
- root :to => "article#index"
+ root to: "article#index"
```
### Wrapup
@@ -239,7 +239,7 @@ The key ideas of HAML include:
%p.flash= flash[:notice]
- = link_to "New Article", new_article_path, :class => 'new_article'
+ = link_to "New Article", new_article_path, class: 'new_article'
#sidebar Filter by Tag: #{tag_links(Tag.all)}
@@ -26,7 +26,7 @@ As an example, create `views/articles/_comments.html.haml` and move the H3 and e
Now, to render the partial we utilize the `render` method. At the bottom of `show.html.haml`, add:
```haml
-= render :partial => 'comments'
+= render partial: 'comments'
```
Refresh your browser and the comments will be back.
@@ -44,13 +44,13 @@ Go to an article's `show` page in your browser, and it will crash because it can
Open `app/views/articles/show.html.haml` and change this:
```haml
-= render :partial => 'comments'
+= render partial: 'comments'
```
to this:
```haml
-= render :partial => 'common/comments'
+= render partial: 'common/comments'
```
When `render` sees a `/` in the partial name, it interprets the first part as the folder name and the second as the file name.
@@ -64,14 +64,14 @@ To see how it works, first go into your partial and change all references from `
Then, in the `show` template, modify the `render` call to this:
```haml
-= render :partial => 'common/comments', :locals => {:article => @article}
+= render partial: 'common/comments', locals: {article: @article}
```
The `locals` option takes a hash. Each key will be setup as a local variable and the value stored into the variable. So, in the context of the partial, we'll now have an `article` variable holding `@article`.
Refresh the `show` page in your browser and it should render correctly.
-To make the partial truly reusable, we should edit it to refer to a local variable named `subject` then, when rendering it, pass in `:subject => @article`.
+To make the partial truly reusable, we should edit it to refer to a local variable named `subject` then, when rendering it, pass in `subject: @article`.
## Rendering Collections
@@ -90,13 +90,13 @@ Refresh your index page and the articles will disappear.
We want to render the LIs inside the `%ul#articles`. Let's try it in one line:
```haml
-%ul#articles= render :partial => 'article_item'
+%ul#articles= render partial: 'article_item'
```
That's a good start, but we don't want to render it *once*, we need to render it *once for each article*. Add the `:collection` parameter like this:
```haml
-%ul#articles= render :partial => 'article_item', :collection => @articles
+%ul#articles= render partial: 'article_item', collection: @articles
```
Refresh your browser and it still crashes. The partial is looking for a variable named `article` but can't find one.
@@ -113,7 +113,7 @@ To make our view work, we have two options.
Implement the second option, renaming the file. Then update the `render` call like this:
```haml
-%ul#articles= render :partial => 'article', :collection => @articles
+%ul#articles= render partial: 'article', collection: @articles
```
Refresh your browser and the view should display correctly.
@@ -123,7 +123,7 @@ Refresh your browser and the view should display correctly.
When we first rendered the comments partial, you might have known that instead of:
```haml
-= render :partial => 'comments'
+= render partial: 'comments'
```
We could have just written this:
@@ -135,13 +135,13 @@ We could have just written this:
If you give `render` a string, it will attempt to render a partial with that name. But, due to implementation details of the `render` method, you *cannot* leave off the `:partial` and still use `:locals`:
```haml
-= render 'comments', :locals => {:article => @article}
+= render 'comments', locals: {article: @article}
```
Nor can you leave off `:partial` when rendering a collection. This *will not work*:
```haml
-%ul#articles= render 'article', :collection => @articles
+%ul#articles= render 'article', collection: @articles
```
There is a shortened syntax that *will* work. You can do this:
@@ -158,7 +158,7 @@ There is a shortened syntax that *will* work. You can do this:
A few last thoughts on view partials:
-* For consistency, use the syntax `render :partial => x` and `render :partial => x, :collection => y`
+* For consistency, use the syntax `render partial: x` and `render partial: x, collection: y`
* An `app/views/common` folder is helpful on most projects to hold reusable partials
* Generally, don't next partials more than two levels deep:
Example:
@@ -154,7 +154,7 @@ You've used `have_link` and know there is a link with the text of the article ti
Use the `:href` option to check that the link points to the article's `show` page. As a reminder, the API looks like this:
```ruby
-page.should have_link(text_or_id, :href => <destination>)
+page.should have_link(text_or_id, href: <destination>)
```
#### A JavaScript Sample
@@ -166,8 +166,8 @@ First, we need to write an example and tell it to use the current JavaScript eng
The structure of the example will be:
```ruby
-it "should show the page title in all caps", :js => true do
- page.should have_selector("h1", :text => "ALL ARTICLES")
+it "should show the page title in all caps", js: true do
+ page.should have_selector("h1", text: "ALL ARTICLES")
end
```
@@ -231,4 +231,4 @@ These may include adding significant functionality to the Rails application itse
* when there are multiple (_n_, where _n_ is an integer) comments, the heading should say "_n_ Comments"
* When on the articles index page
* Clicking a tag should show only articles with that tag
- * A tag should not appear in the list if it has no associated articles
+ * A tag should not appear in the list if it has no associated articles
@@ -98,7 +98,7 @@ The `within` method allows you to scope all your actions down to a certain secti
```ruby
within("#articles") do
- page.should have_link(article.title, :href => article_path(article))
+ page.should have_link(article.title, href: article_path(article))
end
```
@@ -113,9 +113,9 @@ You can check out all the actions available here: http://rubydoc.info/github/jni
The most useful are:
* `click_on(locator)` (alias for `click_link_or_button`)
-* `fill_in(locator, :with => "My Data")`
+* `fill_in(locator, with: "My Data")`
-You can click on any link or button by using `click_on` and a CSS-style locator. You can fill in text fields or areas by using `fill_in` with a CSS selector and the `:with =>` option to send in the data.
+You can click on any link or button by using `click_on` and a CSS-style locator. You can fill in text fields or areas by using `fill_in` with a CSS selector and the `with:` option to send in the data.
### Capybara-RSpec Matchers
@@ -169,9 +169,9 @@ Imagine that our `articles/index` DOM is going to have a link with the text "Cre
```ruby
visit articles_path
page.should have_link("Create a New Article")
-page.should have_link("Create a New Article", :href => new_article_path)
+page.should have_link("Create a New Article", href: new_article_path)
page.should have_link("new_article")
-page.should have_link("new_article", :href => new_article_path)
+page.should have_link("new_article", href: new_article_path)
```
Which is the right choice? During an application lifetime, the copy text is unstable. It's very likely that the link could change to "Write a New Article" as it goes through UI revisions. For that reason, the first two options are poor choices.
@@ -206,7 +206,7 @@ That matcher validates that there is, specifically, an H2 tag with the ID `"arti
```ruby
visit article_path(article)
-page.should have_selector("h2#article_title", :text => article.title)
+page.should have_selector("h2#article_title", text: article.title)
```
This can be a great tool when you're validating the functionality of a form. Visit the form, fill it in, submit it, then verify that the resulting page has the text you entered in an H2 tag.
@@ -223,7 +223,7 @@ You'll notice that there are `_no_` methods like `has_no_content?` defined in `C
```ruby
visit article_path(article)
-page.should_not have_selector("h1", :text => "All Articles)
+page.should_not have_selector("h1", text: "All Articles)
```
-This relies on RSpec's built in `should_not` rather than handling the negation with the Capybara selector.
+This relies on RSpec's built in `should_not` rather than handling the negation with the Capybara selector.
@@ -32,17 +32,17 @@ If you have Firefox 4 installed then there are no extra setup steps. It's possib
### Modifying Your Examples
-If you want to only use the browser for a few specific tests, you can add `:js => true` into the `it` line like this:
+If you want to only use the browser for a few specific tests, you can add `js: true` into the `it` line like this:
```ruby
-it "should list the article titles on the index", :js => true do
+it "should list the article titles on the index", js: true do
@articles.each do |article|
page.should have_link(article.title)
end
end
```
-More commonly you'll have a group of tests that you want to run in the browser. Rather than litter `:js => true` all over the place, do this:
+More commonly you'll have a group of tests that you want to run in the browser. Rather than litter `js: true` all over the place, do this:
* Create a `describe` block that contains the examples that need JavaScript
* Add a before-all block like this:
@@ -135,7 +135,7 @@ gem 'capybara-webkit'
At the time of this writing, it was necessary to use the 1.0 branch of capybara-webkit like this:
```ruby
-gem "capybara-webkit", :git => "https://github.com/thoughtbot/capybara-webkit.git", :branch => "1.0"
+gem "capybara-webkit", git: "https://github.com/thoughtbot/capybara-webkit.git", branch: "1.0"
```
### Tell Capybara about Capybara-Webkit
@@ -148,7 +148,7 @@ Capybara.javascript_driver = :webkit
### Run Your Examples
-Now all you do is run your examples! We just swapped the driver, but the way we tell Capybara to use it is exactly the same as Selenium. If you want to run a single test with WebKit, add `:js => true` to the `it` line.
+Now all you do is run your examples! We just swapped the driver, but the way we tell Capybara to use it is exactly the same as Selenium. If you want to run a single test with WebKit, add `js: true` to the `it` line.
If you have a set of examples to run with JavaScript, wrap them in a `describe` block with a before-all and after-all like this:
@@ -166,4 +166,4 @@ describe "run with webkit" do
end
```
-You'll practice using the JavaScript-enabled drivers in the exercises in the next section.
+You'll practice using the JavaScript-enabled drivers in the exercises in the next section.
@@ -94,7 +94,7 @@ Providing code coverage documentation is extremely simple if you use the [Simple
1. Add SimpleCov to your `Gemfile` and then `bundle install`:
```ruby
- gem 'simplecov', :require => false, :group => :test
+ gem 'simplecov', require: false, group: :test
```
2. Load and launch SimpleCov *at the very top* of your `test/test_helper.rb`:
@@ -10,7 +10,7 @@ module ResourceController
extend ActiveSupport::Concern
included do
- before_filter :find_resource, :only => [:show, :edit, :update, :destroy]
+ before_filter :find_resource, only: [:show, :edit, :update, :destroy]
end
module InstanceMethods
Oops, something went wrong.

0 comments on commit a10fb50

Please sign in to comment.