README.rdoc in inherited_resources-1.3.0 vs README.rdoc in inherited_resources-1.3.1

@@ -1,12 +1,20 @@
+=== Deprecation notice
+
+Since Rails 3 came out, I have no longer used Inherited Resources. I have found that the
+responders abstraction and custom Rails generators offer the perfect balance between
+hiding and showing too much logic. That said, I suggest developers to make use of the
+responders gem (at https://github.com/plataformatec/responders) and no longer use Inherited
+Resources.
+
 == Inherited Resources
 
 Inherited Resources speeds up development by making your controllers inherit
 all restful actions so you just have to focus on what is important. It makes
 your controllers more powerful and cleaner at the same time.
 
-Plus, making your controllers follow a pattern, it helps you to write better
+In addition to making your controllers follow a pattern, it helps you to write better
 code by following fat models and skinny controllers convention. There are
 two screencasts available besides this README:
 
 * http://railscasts.com/episodes/230-inherited-resources
 * http://akitaonrails.com/2009/09/01/screencast-real-thin-restful-controllers-with-inherited-resources
@@ -21,11 +29,11 @@
 
 And then execute:
 
   bundle install 
 
-Or install it yourself as:
+Or install it yourself with:
 
   gem install inherited_resources
 
 === Rails 2.3.x
 
@@ -55,11 +63,11 @@
 InheritedResources controllers. Be sure to check the documentation to see
 how it will change your application:
 
   http://github.com/plataformatec/responders
 
-And it can be installed as:
+And it can be installed with:
 
   gem install responders
 
 Using responders will set the flash message to :notice and :alert. You can change
 that through the following configuration value:
@@ -83,19 +91,19 @@
 
     class ProjectsController < InheritedResources::Base
       respond_to :html, :xml, :json
     end
 
-You can also specify them based per action:
+You can also specify them per action:
 
     class ProjectsController < InheritedResources::Base
       respond_to :html, :xml, :json
       respond_to :js, :only => :create
       respond_to :iphone, :except => [ :edit, :update ]
     end
 
-For each request, it first checkes if the "controller/action.format" file is
+For each request, it first checks if the "controller/action.format" file is
 available (for example "projects/create.xml") and if it's not, it checks if
 the resource respond to :to_format (in this case, :to_xml). Otherwise returns 404.
 
 Another option is to specify which actions the controller will inherit from
 the InheritedResources::Base:
@@ -127,23 +135,23 @@
     end
 
 == Overwriting defaults
 
 Whenever you inherit from InheritedResources, several defaults are assumed.
-For example you can have an AccountsController to account management while the
-resource is an User:
+For example you can have an AccountsController for account management while the
+resource is a User:
 
     class AccountsController < InheritedResources::Base
       defaults :resource_class => User, :collection_name => 'users', :instance_name => 'user'
     end
 
 In the case above, in your views you will have @users and @user variables, but
 the routes used will still be accounts_url and account_url. If you plan also to
 change the routes, you can use :route_collection_name and :route_instance_name.
 
 Namespaced controllers work out of the box, but if you need to specify a
-different route prefix, you can do the following:
+different route prefix you can do the following:
 
     class Administrators::PeopleController < InheritedResources::Base
       defaults :route_prefix => 'admin'
     end
 
@@ -165,14 +173,14 @@
 The end_of_association_chain returns your resource after nesting all associations
 and scopes (more about this below).
 
 InheritedResources also introduces another method called begin_of_association_chain.
 It's mostly used when you want to create resources based on the @current_user and
-you have urls like "account/projects". In such cases, you have to do
+you have urls like "account/projects". In such cases you have to do
 @current_user.projects.find or @current_user.projects.build in your actions.
 
-You can deal with it just doing:
+You can deal with it just by doing:
 
     class ProjectsController < InheritedResources::Base
       protected
         def begin_of_association_chain
           @current_user
@@ -202,12 +210,12 @@
           format.html { redirect_to root_url }
         end
       end
     end
 
-Even more, since most of the times when you change a create, update or destroy
-action is because you want to to change to where it redirects, a shortcut is
+Since most of the time when you change a create, update or destroy
+action you do so because you want to to change its redirect url, a shortcut is 
 provided. So you can do:
 
     class ProjectsController < InheritedResources::Base
       def destroy
         destroy!{ root_url }
@@ -241,11 +249,11 @@
         @project.something_special!
         create!
       end
     end
 
-Yes, that simple! The nice part is since you already set the instance variable
+Yes, it's that simple! The nice part is since you already set the instance variable
 @project, it will not build a project again.
 
 Before we finish this topic, we should talk about one more thing: "success/failure
 blocks". Let's suppose that when we update our project, in case of failure, we
 want to redirect to the project url instead of re-rendering the edit template.
@@ -260,34 +268,34 @@
           end
         end
      end
     end
 
-Looks to verbose, right? We can actually do:
+Looks too verbose, right? We can actually do:
 
     class ProjectsController < InheritedResources::Base
       def update
         update! do |success, failure|
           failure.html { redirect_to project_url(@project) }
         end
       end
     end
 
 Much better! So explaining everything: when you give a block which expects one
-argument it will be executed in both scenarios: success and failure. But If you
+argument it will be executed in both scenarios: success and failure. But if you
 give a block that expects two arguments, the first will be executed only in
 success scenarios and the second in failure scenarios. You keep everything
 clean and organized inside the same action.
 
 == Smart redirects
 
 Although the syntax above is a nice shortcut, you won't need to do it frequently
 because (since version 1.2) Inherited Resources has smart redirects. Redirects
 in actions calculates depending on the existent controller methods.
 
-Redirects in create and update actions calculates in following order resource_url,
-collection_url, parent_url (which we are going to see later), root_url. Redirect
+Redirects in create and update actions calculates in the following order resource_url,
+collection_url, parent_url (which we are going to see later), and root_url. Redirect
 in destroy action calculate in following order collection_url, parent_url, root_url.
 
 Example:
 
     class ButtonsConntroller < InheritedResources::Base
@@ -504,10 +512,10 @@
 index actions accordingly). Also, it will produce delete_resource_{path,url} and 
 search_resources_{path,url} url helpers.
 
 == What about views?
 
-Sometimes just DRY the controllers is not enough, if you need to DRY up your views,
+Sometimes just DRYing up the controllers is not enough. If you need to DRY up your views,
 check this Wiki page:
 
 https://github.com/josevalim/inherited_resources/wiki/Views-Inheritance
 
 Notice that Rails 3.1 ships with view inheritance built-in.