Inherited Resources is scopes and responder fluent

First, what is Inherited Resources?

Inherited Resources is a gem/plugin that allows you to speed up development by making your controllers inherit all restful actions so you just have to focus on what is important. A Rails scaffold controller which responds to html, xml and json is as simple as:

class ProjectsController 

However all actions are still customizable! For example, you can change the behavior of the create action on success just doing:

class ProjectsController 

It also supports I18n (all flash messages are set with I18n), belongs to association (like a task belongs to project), nested belongs to (task belongs to project which belongs to company), polymorphic belongs to (comments belong to task or file or message) and optional belongs to (the same as previously, but you can request the resource with or without parents).

As you noticed, besides simplifying your controllers, InheritedResouces makes easy to reproduce your models behavior and relationship in controllers. And right now, it's also scopes and responder fluent!

has_scope: named_scope twin brother

Let's suppose that we have a ProjectsController and at some point you want to add some filters on the index action like showing just featured projects, selecting projects by methodology or even let the user choose how many projects he can see per page. The first thing to do? Add named scopes to your model:

class Project  { :featured => true }
  named_scope :by_methodology, proc {|methodology| { :conditions => { :methodology => methodology } } }
  named_scope :limit, proc{|limit| :limit => limit.to_i }
end

The next step would be to add a lot of code in your controllers that check which named scopes you should call, based on the parameters sent right? Well, not anymore. Your controller can be as simple as:

class ProjectsController  true
  has_scope :by_methodology
  has_scope :limit, :default => 10, :only => :index
end

Then for each request:

/projects
#=> acts like a normal request, but returning only 10 projects

/projects?featured=true
#=> calls the featured named scope and bring 10 featured projects

/projects?featured=true&by_methodology=agile&limit=20
#=> brings 20 featured projects with methodology agile

If you configure your routes, you could even have pretty urls with it:

/projects/agile/featured
#=> brings 10 featured projects with methodology agile

Yay!

Responder

A couple weeks ago, we wrote about ActionController::Responder. But you don't have to wait Rails 3 to be released to play with it, you can start now by using Inherited Resources.

Quick redirect

After using Inherited Resouces, I realized that most of the times I overwrite a create, update or destroy actions is to change the redirect destination. In our ProjectsController above, if we want to redirect to the edit page after create, we would have to do:

class ProjectsController 

It wouldn't be cool if it have a shortcut? Now it has:

class ProjectsController 

That simple, just give the url as a proc and since the proc does not expect any parameters, it assumes that you want to overwrite the redirect url.

Finally some DSL?

Last weeks, there was a discussion on Boston.rb group about different resource controllers gems. Reading some of the feedback there, I've decided to stab a DSL to Inherited Resources. It will mainly remove the duplication when you have to give a block, the previous example above could be written as:

class ProjectsController 

Or even in the compact form:

class ProjectsController 

Those changes were not applied yet, it depends mainly on you. If you like or not, let us know in the comments!

52 responses to “Inherited Resources is scopes and responder fluent”

  1. Roger Leite says:

    Great features!
    has_scope and responder would be a wonderful help!
    About the DSL … IMHO, i couldn’t use.

    Success!

  2. Roger Leite says:

    Great features!
    has_scope and responder would be a wonderful help!
    About the DSL … IMHO, i couldn’t use.

    Success!

  3. jblanche says:

    That’s just awesome !
    I want all of it, even if the DSL part looks less interresting to me than the rest.

  4. jblanche says:

    That’s just awesome !
    I want all of it, even if the DSL part looks less interresting to me than the rest.

  5. Diego Caliri says:

    Looks nice! Will try it. I have a project that could use right now the feature

  6. It looks very pretty, I liked it a lot!!
    Mainly the integration between the controlers and the models

  7. It looks very pretty, I liked it a lot!!
    Mainly the integration between the controlers and the models

  8. Ivan says:

    That’s some awesome work, thanks José!

    Would it be too difficult to make has_scope calls accept an :as parameter? For cases when you prefer to code in english but expose to the user in another language. Something like this:

    has_scope :by_methodology, :as => ‘por_metodologia’, :boolean => true

    Or:

    has_scope :by_methodology => ‘por_metodologia’, :boolean => true

  9. Ivan says:

    That’s some awesome work, thanks José!

    Would it be too difficult to make has_scope calls accept an :as parameter? For cases when you prefer to code in english but expose to the user in another language. Something like this:

    has_scope :by_methodology, :as => ‘por_metodologia’, :boolean => true

    Or:

    has_scope :by_methodology => ‘por_metodologia’, :boolean => true

  10. iain says:

    Looks great! I will certainly take a look at it. Two questions though: Can you alter certain behavior globally? I remember that being a pain in the ass to do with other gems (but that was almost a year ago). And do you have a neat trick on how to test the results? Maybe in combination with Remarkable?

  11. iain says:

    Looks great! I will certainly take a look at it. Two questions though: Can you alter certain behavior globally? I remember that being a pain in the ass to do with other gems (but that was almost a year ago). And do you have a neat trick on how to test the results? Maybe in combination with Remarkable?

  12. Awesome! Thanks!!

  13. Awesome! Thanks!!

  14. José Valim says:

    @Ivan there is already an options called :key that does what you suggested. But :as is definitely a better name! I’m going to change that! 🙂

    @iain Whenever I’m using Inherited Resources, I do not write controller specs, just integration ones (unless a controller does not follow IR pattern). So I test such behavior just in integration specs!

  15. José Valim says:

    @Ivan there is already an options called :key that does what you suggested. But :as is definitely a better name! I’m going to change that! 🙂

    @iain Whenever I’m using Inherited Resources, I do not write controller specs, just integration ones (unless a controller does not follow IR pattern). So I test such behavior just in integration specs!

  16. bendycode says:

    +1 for the DSL. It looks like a nice step towards even more declarative power.

  17. bendycode says:

    +1 for the DSL. It looks like a nice step towards even more declarative power.

  18. jackhq says:

    +1 for the DSL, very well put together, can’t wait to give it a try!

  19. jackhq says:

    +1 for the DSL, very well put together, can’t wait to give it a try!

  20. Richie Vos says:

    Has scope seems pretty phenomenal. I’m not using inherited resources but am definitely going to have to track down how you’re implementing that.

  21. Richie Vos says:

    Has scope seems pretty phenomenal. I’m not using inherited resources but am definitely going to have to track down how you’re implementing that.

  22. malkomalko says:

    Jose,

    Great job on the has_scope. Is this actually looking for a named_scope or would it work also for a method defined on the class?

  23. malkomalko says:

    Jose,

    Great job on the has_scope. Is this actually looking for a named_scope or would it work also for a method defined on the class?

  24. José Valim says:

    @malkomalko it also works for methods defined on the class!

  25. José Valim says:

    @malkomalko it also works for methods defined on the class!

  26. malkomalko says:

    Great!

  27. malkomalko says:

    Great!

  28. Rasmus says:

    Looks great. I have a question though.

    Is inhering from InheritedResource::Base just a transition thing while we’re waiting for Rails 3?

  29. Rasmus says:

    Looks great. I have a question though.

    Is inhering from InheritedResource::Base just a transition thing while we’re waiting for Rails 3?

  30. José Valim says:

    @Rasmus, what do you mean?

    Inherited Resources is a plugin and there is no plan to be merged with Rails 3. So that means you still need to inherit from InheritedResources::Base. 🙂

  31. José Valim says:

    @Rasmus, what do you mean?

    Inherited Resources is a plugin and there is no plan to be merged with Rails 3. So that means you still need to inherit from InheritedResources::Base. 🙂

  32. Rasmus says:

    José,

    Thank you for the clarification. I somehow managed to misunderstand that this was a plugin. May I suggest that you write that InheritedResources is a plugin, in the section called “First, what is Inherited Resources?” so that slow people like me understand faster 😉

    Also, reading through the source of the plugin I realized it contains a version of ActionController::Responder. This led me to understand how (and why) the plugin functions with both Rails 2 and 3.

  33. Rasmus says:

    José,

    Thank you for the clarification. I somehow managed to misunderstand that this was a plugin. May I suggest that you write that InheritedResources is a plugin, in the section called “First, what is Inherited Resources?” so that slow people like me understand faster 😉

    Also, reading through the source of the plugin I realized it contains a version of ActionController::Responder. This led me to understand how (and why) the plugin functions with both Rails 2 and 3.

  34. José Valim says:

    Thanks Rasmus! Already updated the post!

  35. José Valim says:

    Thanks Rasmus! Already updated the post!

  36. […] Inherited Resources is scopes and responder fluent | Plataforma Blog […]

  37. Aaron Renoir says:

    Very cool. I am going to use this with all my projects.

    I am having an issue unrelated to has_scope and responder.
    I am using the begin_of_association_chain method to set the current_user and current_domain. It works for a single resource but once I start nesting them it fails to set the domain_id or user_id. I am currently overriding all the update and create actions to add the domain_id and user_id in? Am I missing something?

  38. Aaron Renoir says:

    Very cool. I am going to use this with all my projects.

    I am having an issue unrelated to has_scope and responder.
    I am using the begin_of_association_chain method to set the current_user and current_domain. It works for a single resource but once I start nesting them it fails to set the domain_id or user_id. I am currently overriding all the update and create actions to add the domain_id and user_id in? Am I missing something?

  39. José Valim says:

    @Aaron, I need to see some code in order to reply you. 😉

  40. José Valim says:

    @Aaron, I need to see some code in order to reply you. 😉

  41. José Valim says:

    Aaron, looking to the code at the pastie, the begin of association chain can only set the @current_user OR the @current_domain. So you don’t need to set the one of them in your actions, but you will need to overwrite create and update to set the other.

  42. José Valim says:

    Aaron, looking to the code at the pastie, the begin of association chain can only set the @current_user OR the @current_domain. So you don’t need to set the one of them in your actions, but you will need to overwrite create and update to set the other.

  43. Oleh says:

    Thanks for great plugin!
    I have a question: what approach would you suggest if i want to inherit some of my controllers from SecureController with, say, permissions check in before_filter?

  44. Oleh says:

    Thanks for great plugin!
    I have a question: what approach would you suggest if i want to inherit some of my controllers from SecureController with, say, permissions check in before_filter?

  45. José Valim says:

    @Oleh, you have two options: 1) Move SecureController actions to a module or 2) use your SecureController and call inherit_resources inside your new controller:

    class MyController < SecureController
    inherit_resources
    end

  46. José Valim says:

    @Oleh, you have two options: 1) Move SecureController actions to a module or 2) use your SecureController and call inherit_resources inside your new controller:

    class MyController

  47. Oleh says:

    Thanx! I must read docs more carefully 🙂

  48. Oleh says:

    Thanx! I must read docs more carefully 🙂