Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Rails RESTful controller abstraction plugin. This fork adds Rails 3 support and nothing else.

This branch is even with BDQ:automatic_route_discovery

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


= Resource Controller

resource_controller makes RESTful controllers easier, more maintainable, and super readable.
With the RESTful controller pattern hidden away, you can focus on what makes your controller special.

== Get It

  git clone git://

= Usage

Creating a basic RESTful controller is as easy as inheriting from +ResourceController::Base+

  class PostsController < ResourceController::Base

...or if you prefer, you can use the method-call syntax.  Since +ResourceController::Base+ now properly
supports inheritance, the above way is the preferred way to use +resource_controller+, but this also

  class PostsController < ApplicationController

Both syntaxes are identical in their behavior.

When loaded, +resource_controller+ will actually iterate through all the routes you have defined in +routes.rb+.
A sequence of callbacks is defined for each resource, which can then be customized. For member routes,
the default action will attempt to lookup the record in the model and render it. For collection routes,
the default action will use +find(:all)+ to retrieve all models. Assuming this set of routes:

  map.resources :users, :collection => {:extended_list => :get}, :member => {:rename => :post}

Note that +ResourceController::Base+ itself inherits from +ApplicationController+, so all of your global
filters will still be applied.

Nobody just uses the default RESTful controller, though. +resource_controller+ provides a simple API for customizations.

== Action Lifecycle

It's really easy to make changes to the lifecycle of your actions. For each action, the following
callbacks are executed in order:

  action  # only on non-GET requests

Each of these callbacks can be redefined by calling them on the name of the action: { #do stuff }
  index.flash "Success"

Note: We had to call the new accessor "new_action", since new is somewhat reserved in ruby.

=== Build

Build is called on each request. For default actions created, these will either 
load an object or a collection: { load_collection }  { load_object }

If you have defined a custom resource, you may have to alter these, although +resource_controller+
tries to figure it out. Using our example routes, these would be created for you:

  extended_list { load_collection }
  rename { load_object }

To change one, simply redefine the block.

  extended_list { @users = User.find(:all, :include => [:profile]) }

If you want to change the way all objects are looked up for a given controller, see
below under "Building objects".

=== Action

The +action+ callback is *only* called on non-GET requests. This provides safety against
making changes to your database via the GET request method. In addition, it provides an easy
way to implement those special actions (such as "login") that you would normally wrap in
an +if block.

The following are two examples of RESTful actions created for you:

  create.action  { }
  destroy.action { object.destroy }

If you were building a login method, you might define an +action+ like this:

  login.action { Account.login(params[:login]) }

If this returns true, then the action is considered a success. If it returns
false, then the action is considered a failure.

=== Response (respond_to)

Since +resource_controller+ already understands whether an action was successful or not
based you the +build+ and +action+ calls, you can define two separate +respond_to+

  login.success.wants.html  # login.rhtml
  login.failure.wants.html { render :text => "Your login failed" }

The response type defaults to success, meaning that +wants.html+ == +wants.success.html+:

  login.wants.html  # same as login.success.wants.html

When defining responses, you can add to what's already there:
  class ProjectsController < ResourceController::Base      
    create.wants.js { render :template => "show.rjs" }

Or you can create a whole new block.  This syntax destroys everything that's there, and starts again:

  class ProjectsController < ResourceController::Base      
    create.response do |wants|
      wants.js { render :template => "show.rjs" }

=== Flash

You can also set the flash on a callback basis. The appropriate one will automatically be used:

  class ProjectsController < ResourceController::Base
    create.flash "Can you believe how easy it is to use resource_controller?  Neither could I!"
    create.failure.flash "A major boo-boo happened. Uh-oh!"

== Advanced Usage

=== Before and After

The +before+ callback is used to perform steps once your object or colletion has
been built, but before +action+ is called. Conversely, +after+ is called once
+action+ has been executed, *but only on success*

  class ProjectsController < ResourceController::Base
    new_action.before do
      3.times { }
    create.after do
      # This won't be called on failure
      object.creator = current_user
=== Scoping with Blocks

Because sometimes you want to make a bunch of customizations at once, most of the helpers accept blocks that make grouping calls really easy.  Is it a DSL?  Maybe; maybe not.  But, it's definitely awesome.

  class ProjectsController < ResourceController::Base

    create do
      flash "Object successfully created!"
      wants.js { render :template => "show.rjs" }
      failure.wants.js { render :template => "display_errors.rjs" }
    destroy do
      flash "You destroyed your project.  Good work."
      failure do
        flash "You cannot destroy that project.  Stop trying!"
        wants.js { render :template => "display_errors.rjs" }

=== Rescuing Exceptions

+resource_controller+ also adds a handy way to catch exceptions, and count these as failures.
That way, you don't have to check for failures *and* exceptions everywhere:

  show do
    build { load_object }
    rescues ActiveRecord::RecordNotFound
    wants.failure.html { render :text => "Record not found" }

If you use +rescues+, you can also check the +exception+ accessor to print out the exception
that occurred:

  destroy do
    action { object.destroy }
    rescues ActiveRecord::StatementInvalid
    wants.failure.html { render :text => exception || "Error occurred" }

Remember that exceptions handled with +rescues+ are still counted as failures - this just
prevents your views from blowing up. If you want to ignore certain exceptions, you need
to wrap your +action+ in a begin/end block.

== Helpers (ResourceController::Helpers)

=== Loading objects

You want to add something like pagination to your controller...

  class PostsController < ResourceController::Base
      def collection
        @collection ||= end_of_association_chain.find(:all, :page => {:size => 10, :current => params[:page]})
Or maybe you used a permalink...

  class PostsController < ResourceController::Base
      def object
        @object ||= end_of_association_chain.find_by_permalink(param)

=== Building objects

Maybe you have some alternative way of building objects...

  class PostsController < ResourceController::Base
      def build_object
        @object ||= end_of_association_chain.build_my_object_some_funky_way object_params
...and there are tons more helpers in the ResourceController::Helpers

== Nested Resources

Nested controllers can be a pain, especially if routing is such that you may or may not have a parent.  Not so with Resource Controller.

  class CommentsController < ResourceController::Base
    belongs_to :post
All of the finding, and creation, and everything will be done at the scope of the post automatically.

== Namespaced Resources

...are handled automatically, and any namespaces are always available, symbolized, in array form @ ResourceController::Helpers#namespaces

== Polymorphic Resources

Everything, including url generation is handled completely automatically.  Take this example...
  ## comment.rb
  class Comment
    belongs_to :commentable, :polymorphic => true
  ## comments_controller.rb
  class CommentsController < ResourceController::Base
    belongs_to :post, :product, :user
  *Note:* Your model doesn't have to be polymorphic in the ActiveRecord sense.  It can be associated in whichever way you want.
  ## routes.rb
  map.resources :posts, :has_many => :comments
  map.resources :products, :has_many => :comments
  map.resources :users, :has_many => :comments

All you have to do is that, and +resource_controller+ will infer whichever relationship is present, and perform all the actions at the scope of the parent object.

=== Parent Helpers

You also get some helpers for reflecting on your parent.

  parent?       # => true/false is there a parent present?
  parent_type   # => :post
  parent_model  # => Post
  parent_object # => @post

=== Non-standard resource names

resource_controller supports overrides for every non-standard configuration of resources.

The most common example is where the resource has a different name than the associated model.  Simply overriding the model_name helper will get resource_controller working with your model.

  map.resources :tags
  class PhotoTag < ActiveRecord::Base
  class TagsController < ResourceController::Base
      def model_name
In the above example, the variable, and params will be set to @tag, @tags, and params[:tag].  If you'd like to change that, override object_name.

  def object_name

If you're using a non-standard controller name, but everything else is standard, overriding resource_name will propagate through all of the other helpers.

  map.resources :tags, :controller => "somethings"
  class Tag < ActiveRecord::Base
  class SomethingsController < ResourceController::Base
      def resource_name
Finally, the route_name helper is used by Urligence to determine which url helper to call, so if you have non-standard route names, override it.

  map.resources :tags, :controller => "taggings"
  class Taggings < ActiveRecord::Base
  class TaggingsController < ResourceController::Base
      def route_name

== Url Helpers

Thanks to Urligence, you also get some free url helpers.

No matter what your controller looks like...

  [edit_|new_]object_url # is the equivalent of saying [edit_|new_]post_url(@post)
  [edit_|new_]object_url(some_other_object) # allows you to specify an object, but still maintain any paths or namespaces that are present
  collection_url # is like saying posts_url

Url helpers are especially useful when working with polymorphic controllers.

  # /posts/1/comments
  object_url          # => /posts/1/comments/#{@comment.to_param}
  object_url(comment) # => /posts/1/comments/#{comment.to_param}
  edit_object_url     # => /posts/1/comments/#{@comment.to_param}/edit
  collection_url      # => /posts/1/comments
  # /products/1/comments
  object_url          # => /products/1/comments/#{@comment.to_param}
  object_url(comment) # => /products/1/comments/#{comment.to_param}
  edit_object_url     # => /products/1/comments/#{@comment.to_param}/edit
  collection_url      # => /products/1/comments
  # /comments
  object_url          # => /comments/#{@comment.to_param}
  object_url(comment) # => /comments/#{comment.to_param}
  edit_object_url     # => /comments/#{@comment.to_param}/edit
  collection_url      # => /comments
Or with namespaced, nested controllers...

  # /admin/products/1/options
  object_url          # => /admin/products/1/options/#{@option.to_param}
  object_url(option)  # => /admin/products/1/options/#{option.to_param}
  edit_object_url     # => /admin/products/1/options/#{@option.to_param}/edit
  collection_url      # => /admin/products/1/options
You get the idea.  Everything is automagical!  All parameters are inferred.

== Credits

resource_controller was created, and is maintained by {James Golick}[].
Dynamic route detection and callbacks added by {Nate Wiger}[]

== License

resource_controller is available under the {MIT License}[]
Something went wrong with that request. Please try again.