Determine if action is on member or on collection - ruby-on-rails

Question

I have been trying to find a clean way to determine wether an action (in a rails controller) applies on members or on collection.
For example when you declare in routes.rb
resources :projects
You get the following methods defined "on collections":
index
create
new
and the following are defined on "on members":
update
show
delete
I am trying to find a way to leverage this great pattern in views for example:
<% if #controller.action.applies_on_members? %>
<%= link_to :destroy, :method => "delete", :confirm => "RU Sure" %>
<%= link_to :show, "show" %>
<% end %>
Similarly this could be useful in before_filters
before_filter :find_project, :only_on_members => true
Currently I have to do the following:
before_filter :find_project, :except => [:new, :create, :index, :export_all, :destroy_all, :archive_all]
This is quite annoying and my idea is that all such actions share a common behavior: they are defined on collections.
Does anyone have an idea of how to achieve this in clean way ?
NB: The reason I ask this question is because I am looking for something scalable in terms of development, such that the behavior of before_filters or some partials is automatically inherited by new custom actions.
Who never had to write down something like
<% unless ["new", "index", "some_other_action1", "some_other_action2", "some_other_action3", "some_other_action4"].include? #controller.action_name %>
<%= link_to "Destroy", :project, :method => :delete %>
<% end %>

Answer 1

Almost a year after posting this question, I know have found a reasonable solution for this question.
If we look at what on => :member and on => :collection really do, the difference is basically that on => :member generates a path including the :id param, whereas the on => :collection version does not.
A simple solution would then to test whether params[:id] is blank or not in a custom method. It would look like this (say in application_controller.rb):
class ApplicationController < ActionController::Base
def on_member?
!params[:id].blank?
end
helper_method :on_member? #method will be accessible in views
end
As described in this post for example, we can do something like this in a before_filter:
before_filter :find_project, :if => :on_member?
In views, this allows me to check the kind of method like so:
<% if on_member? %>
<%= link_to :destroy, :method => "delete", :confirm => "RU Sure" %>
<%= link_to :show, "show" %>
<% end %>

Answer 2

First of all, the pattern on operating on collections and their entries is part of REST which is one of the pillars of Rails. What you've identified is essentially what REST calls collections and entries. In theory, you can apply the most common HTTB verbs on either the collection, or an entry within that collection, where: GET; retrieve, PUT; replace, POST; create and DELETE; destroy. Although it's a little unclear what POST would do on a single entry.
In practise, and in Rails, however, you usually use those you've identified:
Collections
Create entry (POST)
View entries (GET)
Entry
Update entry (PUT)
Show entry (GET)
Delete entry (DELETE)
These are the RESTful routes Rails adds. However, as you know Rails also boxes two other actions to implement a user page which can provide the necessary data to these endpoints. (new, edit),
It's rare I see people coming down to these definitions. As I see it there's at least two ways to go about this problem if you really want to solve it (see bottom of the post):
You could monkey-patch "_normalize_callback_options" to get the exact syntax you proposed. This is relatively straight-forward, but if upstream changes anything about the structure, you have to change your patch, thus it's not very sustainable. Therefore I would not recommend that approach, no matter how tasteful the syntastic sugar looks. Of course you could also try to commit this upstream, but it's unlikely to be accepted due to the reasons mentioned below. :-)
Instead I'd put your definitions in an initializer: config/initializer/rest.rb
ENTRY_ACTIONS = [:edit, :new, :show, :delete, :update]
COLLECTION_ACTIONS = [:create, :index]
Then use them in your filters like:
before_filter :find_project, only: ENTRY_ACTIONS
For access in your views, add an entry_action? and collection_action? method to your application helper:
module ApplicationHelper
def entry_action?
ENTRY_ACTIONS.include?(controller.action_name.to_sym)
end
def collection_action?
COLLECTION_ACTIONS.include?(controller.action_name.to_sym)
end
end
Then in your views:
<% if entry_action? %>
# code
<% end %>
I wouldn't extract this to constants myself, but just write the array directly since it's much more clear in my opinion to read when I come back later. Furthermore, most people would have to think twice every time they encounter these methods which is far from optimal.

Answer 3

You're taking a very common problem that's already solved in Rails for us and pretty much turning it upside down. Rather than asking the controller about its state all over your application, you should tell your views and controllers to do what it needs to do however it knows how to do it.
Since you already know for sure that the index, create and new actions apply to "collections" and that update, show and delete apply to "members", you should define each respective controller actions and views to work with such forms of resources.
Going back to the examples you've given, the links should be defined in a partial and have the appropriate view template render the partial.
Your before_filter should be written as before_filter :find_project, :only => [:update, :show, :delete].
Just the thought of seeing calls to #controller.action.applies_on_members? all over the place in your application raises a flag in my mind that you need to rethink your design. Again, you're trying to solve a problem that Rails already takes care of for you.