Question

I search for a working solution for a rather simple problem, but could not find a good explanation.

What I currently have (working) is an index view which contains:

• a form to enter a new element and
• a paginated list of existing elements (using will_paginate).

For the list I am interested in only part of the data, thus I am trying to add a form with filter options and I would like to store the forms content in a cookie (which should be replaced with an per user object stored in the database, but i do not have users yet). What I cannot figure out is how to get the values from the form stored in a cookie (and vice versa) and how to use it together with will_paginated.

What I currently tried to do as a first step is to create an @filter object in my controller and adding the filter form for this object, setting the form options to use the index controller again. This leads to selected filter parameters passed in the params hash to the index controller (visible in the url). But this solution has some drawbacks. first the filters are gone as soon as I change the view (e.g. by creating a new element) and second the @filter object should be the cookie instead.

Here is the code I have so far:

View-partial for filter:

<%= form_for(@filter, :url => {:action => "index"}, :html => {:method => :get}) do |f| %>
  <div class="field">
    <%= f.label :german %><br />
    <%= f.check_box :german %>
  </div>
  <div class="actions">
    <%= f.submit "Filter" %>
  </div>
<% end %>

Controller:

def index
  @word = Word.new
  @filter = Word.new(params[:word])
  @words = Word.paginate(:page => params[:page]).order('word')
  # ....

Can anybody help me? How is such a functionality (filtering results) done in other applications?

Answer 1

So the answer to the question is, use a where clause to include only the matching records in your result.

@words = Word
  .where("german = ?", params[:word][:german] != 0")
  .order('word')
  .paginate(:page => params[:page])

This is a new Rails syntax called Active Relation (AREL for short), which should generally replace the older find and find_by methods. It has several benefits that can improve performance, notably that the SQL it executes (which you can see in your logs) only occurs when it is referenced, not when it is declared. This give you neat ways of defining partial relations (even as named scopes) that you can build up to create simpler statements that combine together.

The order of the various clauses doesn’t matter — AREL will generate the same SQL, but generally I like to follow the order of the underlying SQL,

• where
• joins
• group
• order
• limit
• offset

(limit and offset are handled in your case by the pagination tool).