Fix README.md

README.md

@@ -52,56 +52,32 @@ rails g simple_controller demand/admin/service --no-swagger
 Another option is to specify which actions the controller will inherit from
 the `SimpleController::BaseController`:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   actions :index, :show, :new, :create
 end
-``
+```
 
 Or:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   actions :all, :except => [ :edit, :update, :destroy ]
 end
-``
+```
 
 In your views, you will get the following helpers:
 
-``ruby
+```ruby
 resource        #=> @project
 collection      #=> @projects
 resource_class  #=> Project
-``
+```
 
 As you might expect, collection (`@projects` instance variable) is only
 available
 on index actions.
 
-If for some reason you cannot inherit from `SimpleController::BaseController`, you can
-call inherit_resources in your controller class scope:
-
-``ruby
-class AccountsController < ApplicationController
-  inherit_resources
-end
-``
-
-One reason to use the `inherit_resources` macro would be to ensure that your
-controller
-never responds with the html mime-type. `SimpleController::BaseController` already
-responds to `:html`, and the `respond_to` macro is strictly additive.
-Therefore, if you want to create a controller that, for example, responds ONLY
-via `:js`,
-you will have to write it this way:
-
-``ruby
-class AccountsController < ApplicationController
-  respond_to :js
-  inherit_resources
-end
-``
-
 ## Overwriting defaults
 
 Whenever you inherit from SimpleController, several defaults are assumed.
@@ -109,28 +85,25 @@ For example you can have an `AccountsController` for account management while
 the
 resource is a `User`:
 
-``ruby
+```ruby
 class AccountsController < SimpleController::BaseController
   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`.
+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:
 
-``ruby
+```ruby
 class Administrators::PeopleController < SimpleController::BaseController
   defaults :route_prefix => 'admin'
 end
-``
+```
 
 Then your named routes will be: `admin_people_url`, `admin_person_url` instead
 of `administrators_people_url` and `administrators_person_url`.
@@ -140,7 +113,7 @@ collection and resource methods. The first is called on index action and the
 second on all other actions. Let's suppose you want to add pagination to your
 projects collection:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   protected
     def collection
@@ -148,36 +121,33 @@ class ProjectsController < SimpleController::BaseController
 set_collection_ivar(end_of_association_chain.paginate(:page => params[:page]))
     end
 end
-``
+```
 
 The `end_of_association_chain` returns your resource after nesting all
-associations
-and scopes (more about this below).
+associations and scopes (more about this below).
 
-SimpleController 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
+SimpleController 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
 `@current_user.projects.find` or `@current_user.projects.build` in your actions.
 
 You can deal with it just by doing:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   protected
     def begin_of_association_chain
       @current_user
     end
 end
-``
+```
 
 ## Overwriting actions
 
 Let's suppose that after destroying a project you want to redirect to your
 root url instead of redirecting to projects url. You just have to do:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def destroy
     super do |format|
@@ -185,13 +155,13 @@ class ProjectsController < SimpleController::BaseController
     end
   end
 end
-``
+```
 
 You are opening your action and giving the parent action a new behavior. On
 the other hand, I have to agree that calling super is not very readable. That's
 why all methods have aliases. So this is equivalent:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def destroy
     destroy! do |format|
@@ -199,47 +169,47 @@ class ProjectsController < SimpleController::BaseController
     end
   end
 end
-``
+```
 
 Since most of the time when you change a create, update or destroy
 action you do so because you want to change its redirect url, a shortcut is
 provided. So you can do:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def destroy
     destroy! { root_url }
   end
 end
-``
+```
 
 If you simply want to change the flash message for a particular action, you can
 pass the message to the parent action using the keys `:notice` and `:alert` (as
 you
 would with flash):
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def create
     create!(:notice => "Dude! Nice job creating that project.")
   end
 end
-``
+```
 
 You can still pass the block to change the redirect, as mentioned above:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def create
     create!(:notice => "Dude! Nice job creating that project.") { root_url }
   end
 end
-``
+```
 
 Now let's suppose that before create a project you have to do something special
 but you don't want to create a before filter for it:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def create
     @project = Project.new(params[:project])
@@ -247,7 +217,7 @@ class ProjectsController < SimpleController::BaseController
     create!
   end
 end
-``
+```
 
 Yes, it's that simple! The nice part is since you already set the instance
 variable
@@ -255,7 +225,7 @@ variable
 
 Same goes for updating the project:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def update
     @project = Project.find(params[:id])
@@ -263,7 +233,7 @@ class ProjectsController < SimpleController::BaseController
     update!
   end
 end
-``
+```
 
 Before we finish this topic, we should talk about one more thing:
 "success/failure
@@ -272,7 +242,7 @@ want to redirect to the project url instead of re-rendering the edit template.
 
 Our first attempt to do this would be:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def update
     update! do |format|
@@ -282,11 +252,11 @@ class ProjectsController < SimpleController::BaseController
     end
   end
 end
-``
+```
 
 Looks too verbose, right? We can actually do:
 
-``ruby
+```ruby
 class ProjectsController < SimpleController::BaseController
   def update
     update! do |success, failure|
@@ -294,7 +264,7 @@ class ProjectsController < SimpleController::BaseController
     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
@@ -317,12 +287,12 @@ in destroy action calculate in following order `collection_url`, `parent_url`,
 
 Example:
 
-``ruby
+```ruby
 class ButtonsController < SimpleController::BaseController
   belongs_to :window
   actions :all, :except => [:show, :index]
 end
-``
+```
 
 This controller redirect to parent window after all CUD actions.
 
@@ -334,35 +304,35 @@ order to tell SimpleController that it really failed, you need to add
 errors to your model. So your `before_destroy` callback on the model should
 be something like this:
 
-``ruby
+```ruby
 def before_destroy
   if cant_be_destroyed?
     errors.add(:base, "not allowed")
     false
   end
 end
-``
+```
 
 ## Belongs to
 
 Finally, our Projects are going to get some Tasks. Then you create a
 `TasksController` and do:
 
-``ruby
+```ruby
 class TasksController < SimpleController::BaseController
   belongs_to :project
 end
-``
+```
 
 `belongs_to` accepts several options to be able to configure the association.
 For example, if you want urls like "/projects/:project_title/tasks", you can
 customize how SimpleController find your projects:
 
-``ruby
+```ruby
 class TasksController < SimpleController::BaseController
   belongs_to :project, :finder => :find_by_title!, :param => :project_title
 end
-``
+```
 
 It also accepts `:route_name`, `:parent_class` and `:instance_name` as options.
 Check the
@@ -375,31 +345,31 @@ Now, our Tasks get some Comments and you need to nest even deeper. Good
 practices says that you should never nest more than two resources, but sometimes
 you have to for security reasons. So this is an example of how you can do it:
 
-``ruby
+```ruby
 class CommentsController < SimpleController::BaseController
   nested_belongs_to :project, :task
 end
-``
+```
 
 If you need to configure any of these belongs to, you can nest them using
 blocks:
 
-``ruby
+```ruby
 class CommentsController < SimpleController::BaseController
   belongs_to :project, :finder => :find_by_title!, :param => :project_title do
     belongs_to :task
   end
 end
-``
+```
 
 Warning: calling several `belongs_to` is the same as nesting them:
 
-``ruby
+```ruby
 class CommentsController < SimpleController::BaseController
   belongs_to :project
   belongs_to :task
 end
-``
+```
 
 In other words, the code above is the same as calling `nested_belongs_to`.
 
@@ -409,39 +379,39 @@ We can go even further. Let's suppose our Projects can now have Files, Messages
 and Tasks, and they are all commentable. In this case, the best solution is to
 use polymorphism:
 
-``ruby
+```ruby
 class CommentsController < SimpleController::BaseController
   belongs_to :task, :file, :message, :polymorphic => true
   # polymorphic_belongs_to :task, :file, :message
 end
-``
+```
 
 You can even use it with nested resources:
 
-``ruby
+```ruby
 class CommentsController < SimpleController::BaseController
   belongs_to :project do
     belongs_to :task, :file, :message, :polymorphic => true
   end
 end
-``
+```
 
 The url in such cases can be:
 
-``
+```
 /project/1/task/13/comments
 /project/1/file/11/comments
 /project/1/message/9/comments
-``
+```
 
 When using polymorphic associations, you get some free helpers:
 
-``ruby
+```ruby
 parent?         #=> true
 parent_type     #=> :task
 parent_class    #=> Task
 parent          #=> @task
-``
+```
 
 Right now, Inherited Resources is limited and does not allow you
 to have two polymorphic associations nested.
@@ -453,31 +423,31 @@ belong
 to a task, file or message. You can reuse your polymorphic controller just
 doing:
 
-``ruby
+```ruby
 class CommentsController < SimpleController::BaseController
   belongs_to :task, :file, :message, :optional => true
   # optional_belongs_to :task, :file, :message
 end
-``
+```
 
 This will handle all those urls properly:
 
-``
+```
 /comment/1
 /tasks/2/comment/5
 /files/10/comment/3
 /messages/13/comment/11
-``
+```
 
 This is treated as a special type of polymorphic associations, thus all helpers
 are available. As you expect, when no parent is found, the helpers return:
 
-``ruby
+```ruby
 parent?         #=> false
 parent_type     #=> nil
 parent_class    #=> nil
 parent          #=> nil
-``
+```
 
 ## Singletons
 
@@ -490,26 +460,26 @@ To declare an resource of current controller  as singleton, you just have to
 give the
 `:singleton` option in defaults.
 
-``ruby
+```ruby
 class ManagersController < SimpleController::BaseController
   defaults :singleton => true
   belongs_to :project
   # singleton_belongs_to :project
 end
-``
+```
 
 So now you can use urls like "/projects/1/manager".
 
 In the case of nested resources (when some of the can be singletons) you can
 declare it separately
 
-``ruby
+```ruby
 class WorkersController < SimpleController::BaseController
   #defaults :singleton => true #if you have only single worker
   belongs_to :project
   belongs_to :manager, :singleton => true
 end
-``
+```
 
 This is correspond urls like "/projects/1/manager/workers/1".
 
@@ -519,27 +489,27 @@ It will deal with everything again and hide the action :index from you.
 
 Namespaced controllers works out the box.
 
-``ruby
+```ruby
 class Forum::PostsController < SimpleController::BaseController
 end
-``
+```
 
 Inherited Resources prioritizes the default resource class for the namespaced
 controller in
 this order:
 
-``
+```
 Forum::Post
 ForumPost
 Post
-``
+```
 
 ## URL Helpers
 
 When you use SimpleController it creates some URL helpers.
 And they handle everything for you. :)
 
-``ruby
+```ruby
 # /posts/1/comments
 resource_url               # => /posts/1/comments/#{@comment.to_param}
 resource_url(comment)      # => /posts/1/comments/#{comment.to_param}
@@ -566,14 +536,14 @@ edit_resource_url          # => /users/#{@user.to_param}/edit
 edit_resource_url(user)    # => /users/#{user.to_param}/edit
 collection_url             # => /users
 parent_url                 # => /
-``
+```
 
 Those urls helpers also accepts a hash as options, just as in named routes.
 
-``ruby
+```ruby
 # /projects/1/tasks
 collection_url(:page => 1, :limit => 10) #=> /projects/1/tasks?page=1&limit=10
-``
+```
 
 In polymorphic cases, you can also give the parent as parameter to
 `collection_url`.
@@ -587,11 +557,11 @@ associations, that relies on Rails' `polymorphic_url`).
 Since version 1.2, Inherited Resources allows you to define custom actions in
 controller:
 
-``ruby
+```ruby
 class ButtonsController < SimpleController::BaseController
   custom_actions :resource => :delete, :collection => :search
 end
-``
+```
 
 This code creates delete and search actions in controller (they behaves like
 show and