draper 1.2.0 → 1.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 6999024e08aa85abe3f852f42feb88106ac36526
-  data.tar.gz: 17506815fb0541ee7cdb93edf9c276341ebcc6a9
+  metadata.gz: 0f6bd44145856c0f804f44cd0bc8fc38490dd37d
+  data.tar.gz: fc320b6749db7c272ba791f118774f2bc01640dd
 SHA512:
-  metadata.gz: 8f0a6c592cf8855a39842d4d158497f27d600bc42bd6e4fcab2ebd0989dfed5d9ba813dcc6830f19955fce994decca51a6acb336669332704c2c6fbdff287bc9
-  data.tar.gz: 737723f0cf15ebf8badc8279359e559f03214a0ab88157f67fcd7ec1365fc79e8e66a29f5bff436474615c3c02e48b57f254d1c858f15925b542093b8c5250cb
+  metadata.gz: 6d6fa20641f68112dba5e37c4e9b355b4f1f11f39cc3f7812e4e2631cf303bcc935f3c5d81265adaf0e96ae907bb60934b1eb047bdd2d2b9236eac9eb767a566
+  data.tar.gz: c92ef62f75eef8d105887c5be659171981ca59287da7b060d49755c608f3d1e50b0ef79da898c0586c2aaaccf50d7037059fe457cae2a3b3e294f18661f31535

data/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Draper Changelog
 
+## 1.2.1
+
+[28 commits by 4 authors](https://github.com/drapergem/draper/compare/v1.2.0...v1.2.1)
+
+* [Document stubbing route helpers](https://github.com/drapergem/draper/commit/dbe8a81ca7d4d9ae87b4b62926a0ba6379397fbc)
+
+* [Rename `source` to `object`. `source` still works, but will be depreciated in a future release.](https://github.com/drapergem/draper/commit/4b933ef39d252ecfe93c573a072633be545c49fb)
+
+Various bugfixes, as always.
+
 ## 1.2.0
 
 [78 commits by 14 authors](https://github.com/drapergem/draper/compare/v1.1.0...v1.2.0)

data/README.md

@@ -3,13 +3,20 @@
 [![TravisCI Build Status](https://secure.travis-ci.org/drapergem/draper.png?branch=master)](http://travis-ci.org/drapergem/draper)
 [![Code Climate](https://codeclimate.com/github/drapergem/draper.png)](https://codeclimate.com/github/drapergem/draper)
 
-Draper adds an object-oriented layer of presentation logic to your Rails application.
+Draper adds an object-oriented layer of presentation logic to your Rails
+application.
 
-Without Draper, this functionality might have been tangled up in procedural helpers or adding bulk to your models. With Draper decorators, you can wrap your models with presentation-related logic to organise - and test - this layer of your app much more effectively.
+Without Draper, this functionality might have been tangled up in procedural
+helpers or adding bulk to your models. With Draper decorators, you can wrap your
+models with presentation-related logic to organise - and test - this layer of
+your app much more effectively.
 
 ## Why Use a Decorator?
 
-Imagine your application has an `Article` model. With Draper, you'd create a corresponding `ArticleDecorator`. The decorator wraps the model, and deals *only* with presentational concerns. In the controller, you decorate the article before handing it off to the view:
+Imagine your application has an `Article` model. With Draper, you'd create a
+corresponding `ArticleDecorator`. The decorator wraps the model, and deals
+*only* with presentational concerns. In the controller, you decorate the article
+before handing it off to the view:
 
 ```ruby
 # app/controllers/articles_controller.rb
@@ -18,9 +25,13 @@ def show
 end
 ```
 
-In the view, you can use the decorator in exactly the same way as you would have used the model. But whenever you start needing logic in the view or start thinking about a helper method, you can implement a method on the decorator instead.
+In the view, you can use the decorator in exactly the same way as you would have
+used the model. But whenever you start needing logic in the view or start
+thinking about a helper method, you can implement a method on the decorator
+instead.
 
-Let's look at how you could convert an existing Rails helper to a decorator method. You have this existing helper:
+Let's look at how you could convert an existing Rails helper to a decorator
+method. You have this existing helper:
 
 ```ruby
 # app/helpers/articles_helper.rb
@@ -33,17 +44,27 @@ def publication_status(article)
 end
 ```
 
-But it makes you a little uncomfortable. `publication_status` lives in a nebulous namespace spread across all controllers and view. Down the road, you might want to display the publication status of a `Book`. And, of course, your design calls for a slighly different formatting to the date for a `Book`.
+But it makes you a little uncomfortable. `publication_status` lives in a
+nebulous namespace spread across all controllers and view. Down the road, you
+might want to display the publication status of a `Book`. And, of course, your
+design calls for a slighly different formatting to the date for a `Book`.
 
-Now your helper method can either switch based on the input class type (poor Ruby style), or you break it out into two methods, `book_publication_status` and `article_publication_status`. And keep adding methods for each publication type...to the global helper namespace. And remember all the names. Ick.
+Now your helper method can either switch based on the input class type (poor
+Ruby style), or you break it out into two methods, `book_publication_status` and
+`article_publication_status`. And keep adding methods for each publication
+type...to the global helper namespace. And remember all the names. Ick.
 
-Ruby thrives when we use Object-Oriented style. If you didn't know Rails' helpers existed, you'd probably imagine that your view template could feature something like this:
+Ruby thrives when we use Object-Oriented style. If you didn't know Rails'
+helpers existed, you'd probably imagine that your view template could feature
+something like this:
 
 ```erb
 <%= @article.publication_status %>
 ```
 
-Without a decorator, you'd have to implement the `publication_status` method in the `Article` model. That method is presentation-centric, and thus does not belong in a model.
+Without a decorator, you'd have to implement the `publication_status` method in
+the `Article` model. That method is presentation-centric, and thus does not
+belong in a model.
 
 Instead, you implement a decorator:
 
@@ -61,19 +82,27 @@ class ArticleDecorator < Draper::Decorator
   end
 
   def published_at
-    source.published_at.strftime("%A, %B %e")
+    object.published_at.strftime("%A, %B %e")
   end
 end
 ```
 
-Within the `publication_status` method we use the `published?` method. Where does that come from? It's a method of the  source `Article`, whose methods have been made available on the decorator by the `delegate_all` call above.
+Within the `publication_status` method we use the `published?` method. Where
+does that come from? It's a method of the  source `Article`, whose methods have
+been made available on the decorator by the `delegate_all` call above.
 
-You might have heard this sort of decorator called a "presenter", an "exhibit", a "view model", or even just a "view" (in that nomenclature, what Rails calls "views" are actually "templates"). Whatever you call it, it's a great way to replace procedural helpers like the one above with "real" object-oriented programming.
+You might have heard this sort of decorator called a "presenter", an "exhibit",
+a "view model", or even just a "view" (in that nomenclature, what Rails calls
+"views" are actually "templates"). Whatever you call it, it's a great way to
+replace procedural helpers like the one above with "real" object-oriented
+programming.
 
 Decorators are the ideal place to:
 * format complex data for user display
-* define commonly-used representations of an object, like a `name` method that combines `first_name` and `last_name` attributes
-* mark up attributes with a little semantic HTML, like turning a `url` field into a hyperlink
+* define commonly-used representations of an object, like a `name` method that
+  combines `first_name` and `last_name` attributes
+* mark up attributes with a little semantic HTML, like turning a `url` field
+  into a hyperlink
 
 ## Installation
 
@@ -85,11 +114,13 @@ gem 'draper', '~> 1.0'
 
 And run `bundle install` within your app's directory.
 
-If you're upgrading from a 0.x release, the major changes are outlined [in the wiki](https://github.com/drapergem/draper/wiki/Upgrading-to-1.0).
+If you're upgrading from a 0.x release, the major changes are outlined [in the
+wiki](https://github.com/drapergem/draper/wiki/Upgrading-to-1.0).
 
 ## Writing Decorators
 
-Decorators inherit from `Draper::Decorator`, live in your `app/decorators` directory, and are named for the model that they decorate:
+Decorators inherit from `Draper::Decorator`, live in your `app/decorators`
+directory, and are named for the model that they decorate:
 
 ```ruby
 # app/decorators/article_decorator.rb
@@ -117,7 +148,8 @@ rails generate decorator Article
 
 ### Accessing Helpers
 
-Normal Rails helpers are still useful for lots of tasks. Both Rails' provided helper and those defined in your app can be accessed via the `h` method:
+Normal Rails helpers are still useful for lots of tasks. Both Rails' provided
+helper and those defined in your app can be accessed via the `h` method:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -133,17 +165,20 @@ If writing `h.` frequently is getting you down, you can add...
 include Draper::LazyHelpers
 ```
 
-...at the top of your decorator class - you'll mix in a bazillion methods and never have to type `h.` again.
+...at the top of your decorator class - you'll mix in a bazillion methods and
+never have to type `h.` again.
 (Note: the `capture` method is only available through `h` or `helpers`)
 
 ### Accessing the model
 
-When writing decorator methods you'll usually need to access the wrapped model. While you may choose to use delegation ([covered below](#delegating-methods)) for convenience, you can always use the `source` (or its alias `model`):
+When writing decorator methods you'll usually need to access the wrapped model.
+While you may choose to use delegation ([covered below](#delegating-methods))
+for convenience, you can always use the `object` (or its alias `model`):
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
   def published_at
-    source.published_at.strftime("%A, %B %e")
+    object.published_at.strftime("%A, %B %e")
   end
 end
 ```
@@ -152,13 +187,16 @@ end
 
 ### Single Objects
 
-Ok, so you've written a sweet decorator, now you're going to want to put it in action! A simple option is to call the `decorate` method on your model:
+Ok, so you've written a sweet decorator, now you're going to want to put it in
+action! A simple option is to call the `decorate` method on your model:
 
 ```ruby
 @article = Article.first.decorate
 ```
 
-This infers the decorator from the object being decorated. If you want more control - say you want to decorate a `Widget` with a more general `ProductDecorator` - then you can instantiate a decorator directly:
+This infers the decorator from the object being decorated. If you want more
+control - say you want to decorate a `Widget` with a more general
+`ProductDecorator` - then you can instantiate a decorator directly:
 
 ```ruby
 @widget = ProductDecorator.new(Widget.first)
@@ -168,7 +206,8 @@ This infers the decorator from the object being decorated. If you want more cont
 
 ### Collections
 
-If you have a whole bunch of objects, you can decorate them all in one fell swoop:
+If you have a whole bunch of objects, you can decorate them all in one fell
+swoop:
 
 ```ruby
 @articles = ArticleDecorator.decorate_collection(Article.all)
@@ -180,9 +219,12 @@ If your collection is an ActiveRecord query, you can use this:
 @articles = Article.popular.decorate
 ```
 
-*Note:* In Rails 3, the `.all` method returns an array and not a query. Thus you _cannot_ use the technique of `Article.all.decorate` in Rails 3. In Rails 4, `.all` returns a query so this techique would work fine.
+*Note:* In Rails 3, the `.all` method returns an array and not a query. Thus you
+_cannot_ use the technique of `Article.all.decorate` in Rails 3. In Rails 4,
+`.all` returns a query so this techique would work fine.
 
-If you want to add methods to your decorated collection (for example, for pagination), you can subclass `Draper::CollectionDecorator`:
+If you want to add methods to your decorated collection (for example, for
+pagination), you can subclass `Draper::CollectionDecorator`:
 
 ```ruby
 # app/decorators/articles_decorator.rb
@@ -198,11 +240,17 @@ end
 @articles = ArticlesDecorator.decorate(Article.all)
 ```
 
-Draper decorates each item using its `decorate` method. Alternatively, you can specify a decorator by overriding the collection decorator's `decorator_class` method, or by passing the `:with` option to the constructor.
+Draper decorates each item using its `decorate` method. Alternatively, you can
+specify a decorator by overriding the collection decorator's `decorator_class`
+method, or by passing the `:with` option to the constructor.
 
 #### Using pagination
 
-Some pagination gems add methods to `ActiveRecord::Relation`. For example, [Kaminari](https://github.com/amatsuda/kaminari)'s `paginate` helper method requires the collection to implement `current_page`, `total_pages`, and `limit_value`. To expose these on a collection decorator, you can delegate to the `source`:
+Some pagination gems add methods to `ActiveRecord::Relation`. For example,
+[Kaminari](https://github.com/amatsuda/kaminari)'s `paginate` helper method
+requires the collection to implement `current_page`, `total_pages`, and
+`limit_value`. To expose these on a collection decorator, you can delegate to
+the `object`:
 
 ```ruby
 class PaginatingDecorator < Draper::CollectionDecorator
@@ -210,13 +258,18 @@ class PaginatingDecorator < Draper::CollectionDecorator
 end
 ```
 
-The `delegate` method used here is the same as that added by [Active Support](http://api.rubyonrails.org/classes/Module.html#method-i-delegate), except that the `:to` option is not required; it defaults to `:source` when omitted.
+The `delegate` method used here is the same as that added by [Active
+Support](http://api.rubyonrails.org/classes/Module.html#method-i-delegate),
+except that the `:to` option is not required; it defaults to `:object` when
+omitted.
 
-[will_paginate](https://github.com/mislav/will_paginate) needs you to `delegate :current_page, :per_page, :offset, :total_entries, :total_pages`.
+[will_paginate](https://github.com/mislav/will_paginate) needs you to
+`delegate :current_page, :per_page, :offset, :total_entries, :total_pages`.
 
 ### Decorating Associated Objects
 
-You can automatically decorate associated models when the primary model is decorated. Assuming an `Article` model has an associated `Author` object:
+You can automatically decorate associated models when the primary model is
+decorated. Assuming an `Article` model has an associated `Author` object:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -224,7 +277,8 @@ class ArticleDecorator < Draper::Decorator
 end
 ```
 
-When `ArticleDecorator` decorates an `Article`, it will also use `AuthorDecorator` to decorate the associated `Author`.
+When `ArticleDecorator` decorates an `Article`, it will also use
+`AuthorDecorator` to decorate the associated `Author`.
 
 ### Decorated Finders
 
@@ -236,21 +290,66 @@ class ArticleDecorator < Draper::Decorator
 end
 ```
 
-...which allows you to then call all the normal ActiveRecord-style finders on your `ArticleDecorator` and they'll return decorated objects:
+...which allows you to then call all the normal ActiveRecord-style finders on
+your `ArticleDecorator` and they'll return decorated objects:
 
 ```ruby
 @article = ArticleDecorator.find(params[:id])
 ```
 
+### When to decorate objects
+
+Decorators are supposed to behave very much like the models they decorate, and
+for that reason it is very tempting to just decorate your objects at the start
+of your controller action and then use the decorators throughout. *Don't*.
+
+Because decorators are designed to be consumed by the view, you should only be
+accessing them there. Manipulate your models to get things ready, then decorate
+at the last minute, right before you render the view. This avoids many of the
+common pitfalls that arise from attempting to modify decorators (in particular,
+collection decorators) after creating them.
+
+To help you make your decorators read-only, we have the `decorates_assigned`
+method in your controller. It adds a helper method that returns the decorated
+version of an instance variable:
+
+```ruby
+# app/controllers/articles_controller.rb
+class ArticlesController < ApplicationController
+  decorates_assigned :article
+
+  def show
+    @article = Article.find(params[:id])
+  end
+end
+```
+
+The `decorates_assigned :article` bit is roughly equivalent to
+
+```ruby
+def article
+  @decorated_article ||= @article.decorate
+end
+helper_method :article
+```
+
+This means that you can just replace `@article` with `article` in your views and
+you'll have access to an ArticleDecorator object instead. In your controller you
+can continue to use the `@article` instance variable to manipulate the model -
+for example, `@article.comments.build` to add a new blank comment for a form.
+
 ## Testing
 
-Draper supports RSpec, MiniTest::Rails, and Test::Unit, and will add the appropriate tests when you generate a decorator.
+Draper supports RSpec, MiniTest::Rails, and Test::Unit, and will add the
+appropriate tests when you generate a decorator.
 
 ### RSpec
 
-Your specs are expected to live in `spec/decorators`. If you use a different path, you need to tag them with `type: :decorator`.
+Your specs are expected to live in `spec/decorators`. If you use a different
+path, you need to tag them with `type: :decorator`.
 
-In a controller spec, you might want to check whether your instance variables are being decorated properly. You can use the handy predicate matchers:
+In a controller spec, you might want to check whether your instance variables
+are being decorated properly. You can use the handy predicate matchers:
 
 ```ruby
 assigns(:article).should be_decorated
@@ -259,7 +358,8 @@ assigns(:article).should be_decorated
 assigns(:article).should be_decorated_with ArticleDecorator
 ```
 
-Note that `model.decorate == model`, so your existing specs shouldn't break when you add the decoration.
+Note that `model.decorate == model`, so your existing specs shouldn't break when
+you add the decoration.
 
 #### Spork Users
 
@@ -271,13 +371,18 @@ require 'draper/test/rspec_integration'
 
 ### Isolated tests
 
-In tests, Draper needs to build a view context to access helper methods. By default, it will create an `ApplicationController` and then use its view context. If you are speeding up your test suite by testing each component in isolation, you can eliminate this dependency by putting the following in your `spec_helper` or similar:
+In tests, Draper needs to build a view context to access helper methods. By
+default, it will create an `ApplicationController` and then use its view
+context. If you are speeding up your test suite by testing each component in
+isolation, you can eliminate this dependency by putting the following in your
+`spec_helper` or similar:
 
 ```ruby
 Draper::ViewContext.test_strategy :fast
 ```
 
-In doing so, your decorators will no longer have access to your application's helpers. If you need to selectively include such helpers, you can pass a block:
+In doing so, your decorators will no longer have access to your application's
+helpers. If you need to selectively include such helpers, you can pass a block:
 
 ```ruby
 Draper::ViewContext.test_strategy :fast do
@@ -285,13 +390,40 @@ Draper::ViewContext.test_strategy :fast do
 end
 ```
 
+#### Stubbing route helper functions
+
+If you are writing isolated tests for Draper methods that call route helper
+methods, you can stub them instead of needing to require Rails.
+
+If you are using RSpec, minitest-rails, or the Test::Unit syntax of minitest,
+you already have access to the Draper `helpers` in your tests since they
+inherit from `Draper::TestCase`. If you are using minitest's spec syntax
+without minitest-rails, you can explicitly include the Draper `helpers`:
+
+```ruby
+describe YourDecorator do
+  include Draper::ViewHelpers
+end
+```
+
+Then you can stub the specific route helper functions you need using your
+preferred stubbing technique (this example uses RSpec's `stub` method):
+
+```ruby
+helpers.stub(users_path: '/users')
+```
+
 ## Advanced usage
 
 ### Shared Decorator Methods
 
-You might have several decorators that share similar needs. Since decorators are just Ruby objects, you can use any normal Ruby technique for sharing functionality.
+You might have several decorators that share similar needs. Since decorators are
+just Ruby objects, you can use any normal Ruby technique for sharing
+functionality.
 
-In Rails controllers, common functionality is organized by having all controllers inherit from `ApplicationController`. You can apply this same pattern to your decorators:
+In Rails controllers, common functionality is organized by having all
+controllers inherit from `ApplicationController`. You can apply this same
+pattern to your decorators:
 
 ```ruby
 # app/decorators/application_decorator.rb
@@ -300,7 +432,8 @@ class ApplicationDecorator < Draper::Decorator
 end
 ```
 
-Then modify your decorators to inherit from that `ApplicationDecorator` instead of directly from `Draper::Decorator`:
+Then modify your decorators to inherit from that `ApplicationDecorator` instead
+of directly from `Draper::Decorator`:
 
 ```ruby
 class ArticleDecorator < ApplicationDecorator
@@ -310,9 +443,12 @@ end
 
 ### Delegating Methods
 
-When your decorator calls `delegate_all`, any method called on the decorator not defined in the decorator itself will be delegated to the decorated source. This is a very permissive interface.
+When your decorator calls `delegate_all`, any method called on the decorator not
+defined in the decorator itself will be delegated to the decorated object. This
+is a very permissive interface.
 
-If you want to strictly control which methods are called within views, you can choose to only delegate certain methods from the decorator to the source model:
+If you want to strictly control which methods are called within views, you can
+choose to only delegate certain methods from the decorator to the source model:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -320,7 +456,8 @@ class ArticleDecorator < Draper::Decorator
 end
 ```
 
-We omit the `:to` argument here as it defaults to the `source` object. You could choose to delegate methods to other places like this:
+We omit the `:to` argument here as it defaults to the `object` being decorated.
+You could choose to delegate methods to other places like this:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -329,7 +466,8 @@ class ArticleDecorator < Draper::Decorator
 end
 ```
 
-From your view template, assuming `@article` is decorated, you could do any of the following:
+From your view template, assuming `@article` is decorated, you could do any of
+the following:
 
 ```ruby
 @article.title # Returns the article's `.title`
@@ -340,15 +478,19 @@ From your view template, assuming `@article` is decorated, you could do any of t
 
 ### Adding context
 
-If you need to pass extra data to your decorators, you can use a `context` hash. Methods that create decorators take it as an option, for example:
+If you need to pass extra data to your decorators, you can use a `context` hash.
+Methods that create decorators take it as an option, for example:
 
 ```ruby
 Article.first.decorate(context: {role: :admin})
 ```
 
-The value passed to the `:context` option is then available in the decorator through the `context` method.
+The value passed to the `:context` option is then available in the decorator
+through the `context` method.
 
-If you use `decorates_association`, the context of the parent decorator is passed to the associated decorators. You can override this with the `:context` option:
+If you use `decorates_association`, the context of the parent decorator is
+passed to the associated decorators. You can override this with the `:context`
+option:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -356,7 +498,8 @@ class ArticleDecorator < Draper::Decorator
 end
 ```
 
-or, if you want to modify the parent's context, use a lambda that takes a hash and returns a new hash:
+or, if you want to modify the parent's context, use a lambda that takes a hash
+and returns a new hash:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -367,7 +510,9 @@ end
 
 ### Specifying Decorators
 
-When you're using `decorates_association`, Draper uses the `decorate` method on the associated record(s) to perform the decoration. If you want use a specific decorator, you can use the `:with` option:
+When you're using `decorates_association`, Draper uses the `decorate` method on
+the associated record(s) to perform the decoration. If you want use a specific
+decorator, you can use the `:with` option:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -375,11 +520,15 @@ class ArticleDecorator < Draper::Decorator
 end
 ```
 
-For a collection association, you can specify a `CollectionDecorator` subclass, which is applied to the whole collection, or a singular `Decorator` subclass, which is applied to each item individually.
+For a collection association, you can specify a `CollectionDecorator` subclass,
+which is applied to the whole collection, or a singular `Decorator` subclass,
+which is applied to each item individually.
 
 ### Scoping Associations
 
-If you want your decorated association to be ordered, limited, or otherwise scoped, you can pass a `:scope` option to `decorates_association`, which will be applied to the collection *before* decoration:
+If you want your decorated association to be ordered, limited, or otherwise
+scoped, you can pass a `:scope` option to `decorates_association`, which will be
+applied to the collection *before* decoration:
 
 ```ruby
 class ArticleDecorator < Draper::Decorator
@@ -389,9 +538,13 @@ end
 
 ### Proxying Class Methods
 
-If you want to proxy class methods to the wrapped model class, including when using `decorates_finders`, Draper needs to know the model class. By default, it assumes that your decorators are named `SomeModelDecorator`, and then attempts to proxy unknown class methods to `SomeModel`.
+If you want to proxy class methods to the wrapped model class, including when
+using `decorates_finders`, Draper needs to know the model class. By default, it
+assumes that your decorators are named `SomeModelDecorator`, and then attempts
+to proxy unknown class methods to `SomeModel`.
 
-If your model name can't be inferred from your decorator name in this way, you need to use the `decorates` method:
+If your model name can't be inferred from your decorator name in this way, you
+need to use the `decorates` method:
 
 ```ruby
 class MySpecialArticleDecorator < Draper::Decorator
@@ -403,11 +556,18 @@ This is only necessary when proxying class methods.
 
 ### Making models decoratable
 
-Models get their `decorate` method from the `Draper::Decoratable` module, which is included in `ActiveRecord::Base` and `Mongoid::Document` by default. If you're [using another ORM](https://github.com/drapergem/draper/wiki/Using-other-ORMs) (including versions of Mongoid prior to 3.0), or want to decorate plain old Ruby objects, you can include this module manually.
+Models get their `decorate` method from the `Draper::Decoratable` module, which
+is included in `ActiveRecord::Base` and `Mongoid::Document` by default. If
+you're [using another
+ORM](https://github.com/drapergem/draper/wiki/Using-other-ORMs) (including
+versions of Mongoid prior to 3.0), or want to decorate plain old Ruby objects,
+you can include this module manually.
 
 ## Contributors
 
-Draper was conceived by Jeff Casimir and heavily refined by Steve Klabnik and a great community of open source [contributors](https://github.com/drapergem/draper/contributors).
+Draper was conceived by Jeff Casimir and heavily refined by Steve Klabnik and a
+great community of open source
+[contributors](https://github.com/drapergem/draper/contributors).
 
 ### Core Team