In
part 1, we explored the use of named scopes in views (more precisely named scoped
names). The named scopes that we used were relatively simple in that they took no arguments.
But what if we have a requirement to filter blog posts by substrings in the title? The named scope would be something of the form:
named_scope :with_title, lambda { |*args| {:conditions => ["title like ?", '%'+args[0]+'%']} }This makes our entire post class look like this:
class Post < ActiveRecord::Base
named_scope :published, :conditions => {:status => 'published'}
named_scope :draft, :conditions => {:status => 'draft'}
named_scope :archived, :conditions => {:status => 'archived'}
named_scope :published_or_draft, :conditions => ["status in ('published', 'archived')"]
named_scope :last_month, lambda { {:conditions => ["updated_at > ?", 1.month.ago]} }
named_scope :last_year, lambda { {:conditions => ["updated_at > ?", 1.year.ago]} }
named_scope :this_month, lambda { {:conditions => ["updated_at > ?", Time.now.beginning_of_month]}}
named_scope :sort_by_title, :order => "title DESC"
named_scope :sort_by_updated, :order => "updated_at DESC"
named_scope :with_title, lambda { |*args| {:conditions => ["title like ?", '%'+args[0]+'%']} }
def published?; status == "published" end
def draft?; status == "draft" end
def archived?; status == "archived" end
end
Recall from
part 1 that we passed all our scopes into the controller in the form:
{:scopes => ["published", "sort_by_title"]}Ideally, I would like to introduce parameterized named scopes to the controller in the form:
{:scopes => [ ["published"],
["sort_by_title"],
["with_title", "foo"] ]}If such a data structure were easily built in forms, then we could almost use the controller code from part 1 without change. Sadly, that is not quite possible.
As a workaround, I choose the convention of passing in named scopes with parameters as hashes.
<div id="filter-by-title-substring">
<input type="text" name="scopes[][with_title]"/>
</div>
This will give us parameters of the form:
{:scopes => [ "published",
"sort_by_title",
{"with_title" => "foo"} ]}Since we are already adding complexity, why not generalize a bit as well? The following code will handle the list-of-strings-and-hashes data structure, plus it will work for any class:
class PostsController < ApplicationController
def index
@posts = scopes_for(Post)
end
private
def scopes_for(klass)
scopes_from_params.inject(klass){|proxy, scope| proxy.send(*scope)}
end
def scopes_from_params
returning scopes = [] do
(params[:scopes] || []).reject(&:blank?).each do |scope|
case scope.class.to_s
when "String"
scopes << [scope] if klass.scopes.include?(scope.to_sym)
when "Hash", "HashWithIndifferentAccess"
msg, arg = scope.first # {:foo => 'bar'}.first => [:foo, "bar"]
scopes << [msg, arg] if klass.scopes.include?(msg.to_sym) && !arg.blank?
end
end
end
scopes.blank? ? [:all] : scopes
end
end
The scopes_for() private method handles the proxy scope injection that was done entirely in the index action from
part 1.
The actual scope calculation is now done in the scopes_from_params method. It still checks the supplied scopes to ensure that they are scopes and not arbitrary methods. It still returns the :all scope if no scopes are supplied. But it also handles our "Hash" case for invoking named scopes with arguments.
The last change is back in the scopes_for method, which now splats the scopes returned from scopes_from_params. If we access the action with the parameters:
{:scopes => [ "published",
"sort_by_title",
{"with_title" => "foo"} ]}We will get the following back from scopes_from_params():
[ ["published"],
["sort_by_title"],
["with_title", "foo"] ]
Injecting these into Post in scopes_for() will result in Post.send("published").send("sort_by_title").send("with_title", "foo"), which is equivalent to Post.published.sort_by_title.with_title("foo)—exactly what we want.
We now have all the benefits from
part 1 (simple views, simple controllers, no magic number coupling between view & controller to handly combo cases like showing published and drafted posts at the same time), plus the ability to use named scopes that take arguments.
