wice_grid 3.4.2 → 3.4.3

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 4b4f8c73e81d3adc0ee032f88f103b1518f89433
+  data.tar.gz: 05867ac703ad3b4b8e8e90d88bcb4edd718c34e8
+SHA512:
+  metadata.gz: a105793df1b9c11d0929beb9cd7c520cd065701ea9a11d76a78bf2f953a6cb5b8e1f17e7ae14ebe578b1bc3b4607af799a2e404e9e54c118a832c78241a98b4b
+  data.tar.gz: 6b9d1a057d0bbc71e90c077cb6ffafa755434107e32a07942a32f2f3bbfa9d72935b172469d542d1e79d5c0c855fc0cbe7a4430ffa563d6d077b784ff1a41711

data/CHANGELOG

@@ -1,11 +1,40 @@
-4.0.1
+3.5.0
+
+External columns processors
+
+Operators '<','>','<=','>=','=' in the integer column
+
+Bugfixes
+
+3.4.1
 
 Support for Bootstrap 3
 
-4.0.0
+3.4.0
 
 Support for Rails 4
 
+3.3.0
+
+The with_paginated_resultset callback receives an ActiveRelation object, not a lambda
+
+Wice::Defaults::DATEPICKER_YEAR_RANGE added to the config to define the default year range in Datepicker (https://github.com/leikind/wice_grid/issues/61)
+
+Improvement of the javascript calendar control: if the FROM field is set to a value after TO, TO is set to the value of FROM.
+Vice versa: if the TO field is set to a value before FROM, FROM is set to the value of TO
+
+New view helpers filter_and_order_state_as_hash(grid) and filter_state_as_hash(grid)
+
+HTML tag caption supported
+
+Support for Ruby 2.0
+
+2 errors fixed in the Saved Queries UI ( https://github.com/leikind/wice_grid/issues/89 )
+
+Bug fixed: extra_request_parameters not propagating to the pagination panel
+
+Documentation improvements
+
 3.2.2
 
 improvement of the javascript calendar control: if the FROM field is set to a value after TO, TO is set to the value of FROM.

data/MIT-LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) 2008 Yuri Leikind & the WICE team (http://wice.eu)
+Copyright (c) 2008-2014 Yuri Leikind
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the

data/README.rdoc

@@ -1,17 +1,20 @@
 = WiceGrid
 
-Version:: 3.4.0
+Version:: 3.4.2
 Author::  Yuri Leikind
 Sources:: https://github.com/leikind/wice_grid/
 Examples online:: http://wicegrid.herokuapp.com
-News:: http://leikind.org/pages/wicegrid/
+News:: http://leikind.org/tag/wicegrid/
 Email::   "Yuri Leikind" <yuri.leikind at gmail dot com>
 
-FOR RAILS 2 USE VERSION 0.6 (https://github.com/leikind/wice_grid/tree/master).
 
-FOR RAILS 3 USE VERSION 3.3.x
+The main supported branch is +rails3+.
 
-FOR RAILS 4 USE VERSION 3.4.x. However with WiceGrid 3.4.0 Rails 4 produdes the following deprecation message:
+For rails 2 use the +master+ branch:  https://github.com/leikind/wice_grid/tree/master
+
+Rails 4 is supported beginning with version 3.4.x.
+
+However, with WiceGrid 3.4.0 Rails 4 produces the following deprecation message:
 
   DEPRECATION WARNING: It looks like you are eager loading table(s) (one of: tasks, statuses) that are referenced in a string SQL snippet. For example:
 
@@ -23,6 +26,8 @@ FOR RAILS 4 USE VERSION 3.4.x. However with WiceGrid 3.4.0 Rails 4 produdes the
 
 This will be fixed in future versions of WiceGrid.
 
+
+
 == Intro
 
 WiceGrid is a Rails grid plugin.
@@ -52,15 +57,13 @@ WiceGrid does not use AJAX calls to reload itself, instead simple GET requests a
 nevertheless, all other page parameters are respected and preserved.
 WiceGrid views do not contain forms so you can include it in your own forms.
 
-There are two major branches of WiceGrid.
-
 WiceGrid is known to work with MySQL and Postgres.
 
 === Examples
 
 This tutorial is accompanied by a sample application with WiceGrid examples which you
-can browse online ( http://wicegrid.herokuapp.com ),
-or just view the code ( https://github.com/leikind/wice_grid_testbed ).
+can browse online: http://wicegrid.herokuapp.com,
+or just view the code: https://github.com/leikind/wice_grid_testbed.
 
 
 == Requirements
@@ -69,23 +72,24 @@ Rails version 3.2.x or newer, jQuery, jQuery Datepicker.
 For Rails 3.0.x and 3.1.x versions use version 3.0.4.
 For Rails 2 use version 0.6 (https://github.com/leikind/wice_grid/tree/master).
 
-WARNING: Since 3.2.pre2 WiceGrid is not compatible with <tt>will_paginate</tt> because internally it uses <tt>kaminari</tt> for pagination, and <tt>kaminari</tt> is not compatible with <tt>will_paginate</tt>!
+WARNING: Since 3.2.pre2 WiceGrid is not compatible with <tt>will_paginate</tt> because internally it
+uses <tt>kaminari</tt> for pagination, and <tt>kaminari</tt> is not compatible with <tt>will_paginate</tt>!
+
 
-== How-To
 
 
-=== Support for javascript frameworks
+== Support for javascript frameworks
 
 WiceGrid started as a plugin using the Prototype javascript framework.
 Support for jQuery was added for version 0.6.
 Beginning from version 3.2 only jQuery is supported.
 
 
-=== Installation
+== Installation
 
 Add the following to your Gemfile:
 
-  gem "wice_grid", '3.2.1'
+  gem "wice_grid", '3.4.2'
 
 and run the <tt>bundle</tt> command.
 
@@ -118,7 +122,7 @@ but if the application uses Twitter Bootstrap, the markup generated by WiceGrid
 Generally it is advised to modify WiceGrid css to match the application style.
 
 
-=== Basics
+== Basics
 
 The simplest example of a WiceGrid for one simple DB table called ApplicationAccount is the following:
 
@@ -164,23 +168,23 @@ Column names are defined with parameter <tt>:name</tt>:
 
   <%= grid(@tasks_grid) do |g|
 
-    g.column :name => 'ID' do |task|
+    g.column name: 'ID' do |task|
       task.id
     end
 
-    g.column :name => 'Title'  do |task|
+    g.column name: 'Title'  do |task|
       task.title
     end
 
-    g.column  :name => 'Description' do |task|
+    g.column name: 'Description' do |task|
       task.description
     end
 
-    g.column  :name => 'Archived' do |task|
+    g.column name: 'Archived' do |task|
       task.archived? ? 'Yes' : 'No'
     end
 
-    g.column   do |task|
+    g.column do |task|
       link_to('Edit', edit_task_path(task))
     end
   end -%>
@@ -190,23 +194,23 @@ table(s) the view column corresponds using parameter <tt>:attribute</tt> :
 
   <%= grid(@tasks_grid) do |g|
 
-    g.column :name => 'ID', :attribute => 'id' do |task|
+    g.column name: 'ID', attribute: 'id' do |task|
       task.id
     end
 
-    g.column :name => 'Title', :attribute => 'title'  do |task|
+    g.column name: 'Title', attribute: 'title'  do |task|
       task.title
     end
 
-    g.column  :name => 'Description', :attribute => 'description' do |task|
+    g.column  name: 'Description', attribute: 'description' do |task|
       task.description
     end
 
-    g.column  :name => 'Archived', :attribute => 'archived' do |task|
+    g.column name: 'Archived', attribute: 'archived' do |task|
       task.archived? ? 'Yes' : 'No'
     end
 
-    g.column   do |task|
+    g.column do |task|
       link_to('Edit', edit_task_path(task))
     end
   end -%>
@@ -231,7 +235,7 @@ Read the section about custom dropdown filters for more advanced filters.
 
 For columns like
 
-  g.column :name => 'Title', :attribute => 'title'  do |task|
+  g.column name: 'Title', attribute: 'title'  do |task|
     task.title
   end
 
@@ -239,17 +243,17 @@ where the block contains just a call to the same attribute declared by :attribut
 
   <%= grid(@tasks_grid) do |g|
 
-    g.column :name => 'ID', :attribute => 'id'
+    g.column name: 'ID', attribute: 'id'
 
-    g.column :name => 'Title', :attribute => 'title'
+    g.column name: 'Title', attribute: 'title'
 
-    g.column  :name => 'Description', :attribute => 'description'
+    g.column name: 'Description', attribute: 'description'
 
-    g.column  :name => 'Archived', :attribute => 'archived' do |task|
+    g.column name: 'Archived', attribute: 'archived' do |task|
       task.archived? ? 'Yes' : 'No'
     end
 
-    g.column   do |task|
+    g.column  do |task|
       link_to('Edit', edit_task_path(task))
     end
   end -%>
@@ -259,18 +263,18 @@ In this case +name+ will be used as the method name to send to the ActiveRecord
 
 If only ordering is needed, and no filter, we can turn off filters using <tt>:filter</tt> :
 
-  g.column :name => 'ID', :attribute => 'id', :filter => false
+  g.column name: 'ID', attribute: 'id', filter: false
 
-If no ordering links are needed, use <tt>:ordering => false</tt>:
+If no ordering links are needed, use <tt>ordering: false</tt>:
 
-  g.column :name => 'Added', :attribute => 'created_at', :ordering => false
+  g.column name: 'Added', attribute: 'created_at', ordering: false
 
 It is important to understand that it is up to the developer to make sure that the value
 returned by a column block (the content of a cell) corresponds to the underlying database
 column specified by  <tt>:attribute</tt> (and <tt>:model</tt> discussed below).
 
 
-=== Rendering filter panel
+== Rendering filter panel
 
 The filter panel can be shown and hidden clicking the icon with binoculars.
 
@@ -284,7 +288,7 @@ Possible values are:
 
 Example:
 
-  <%= grid(@tasks_grid, :show_filters => :always) do |g|
+  <%= grid(@tasks_grid, show_filters: :always) do |g|
     ......
   end -%>
 
@@ -295,35 +299,35 @@ the icons in the additional column, set <tt>Wice::Defaults::REUSE_LAST_COLUMN_FO
 the configuration file.
 
 
-=== Initial Ordering
+== Initial Ordering
 
 Initializing the grid we can also define the column by which the record will be ordered
 <em>on the first rendering of the grid</em>, when the user has not set their ordering
 setting by clicking the column label, and the order direction:
 
   @tasks_grid = initialize_grid(Task,
-    :order => 'tasks.title',
-    :order_direction => 'desc'
+    order:           'tasks.title',
+    order_direction: 'desc'
   )
 
-=== Records Per Page
+== Records Per Page
 
 The number of rows per page is set with <tt>:per_page</tt>:
 
-  @tasks_grid = initialize_grid(Task, :per_page => 40)
+  @tasks_grid = initialize_grid(Task, per_page: 40)
 
-=== Conditions
+== Conditions
 
 The +initialize_grid+ method supports a <tt>:conditions</tt> parameter which is passed
 on to the underlying ActiveRecord, so it can be in any format processable by ActiveRecord:
 
   @tasks_grid = initialize_grid(Task,
-    :conditions => ["archived = false and estimated_time > ?", 100]
+    conditions: ["archived = false and estimated_time > ?", 100]
   )
 
   @tasks_grid = initialize_grid(Task,
-    :include => :project,
-    :conditions => {:archived => false, :project => {:active => true}}
+    include:    :project,
+    conditions: {archived: false, project: {active: true}}
   )
 
 
@@ -334,14 +338,15 @@ A good example is substituting a common pattern like
 
 with WiceGrid code:
 
-  @user_groups_grid = initialize_grid(UserGroup, :conditions => ['portal_application_id = ?', @portal_application])
+  @user_groups_grid = initialize_grid(
+    UserGroup,
+    conditions: ['portal_application_id = ?', @portal_application]
+  )
 
 Alternatively, instead of a Class object as the first parameter, you can use  ActiveRecord::Relation:
 
-
-  @tasks_grid = initialize_grid(Task.
-    where(:archived => false, :projects => {:active => true}).
-    joins(:project)
+  @tasks_grid = initialize_grid(
+    Task.where(archived: false, projects: {active: true}).joins(:project)
   )
 
 
@@ -349,19 +354,19 @@ Please note that though all queries inside of WiceGrid are run without the defau
 scope, if you use an ActiveRecord::Relation instance to initialize grid, it will
 already include the default scope. Thus you might consider using <tt>unscoped</tt>:
 
-  @tasks_grid = initialize_grid(Task.unscoped.
-    where(:archived => false, :projects => {:active => true}).
-    joins(:project)
+  @tasks_grid = initialize_grid(
+    Task.unscoped.where(archived: false, projects: {active: true}).joins(:project)
   )
 
-=== Queries with join tables
+== Queries with join tables
 
 WiceGrid also supports ActiveRecord's <tt>:joins</tt> and <tt>:include</tt>.
 
   @products_grid = initialize_grid(Product,
-    :include => :category,
-    :order => 'products.name',
-    :per_page => 20)
+    include:  :category,
+    order:    'products.name',
+    per_page: 20
+  )
 
 Note that if we want to order initially by a column from a joined table we have to specify the
 table and the column name with the sql dot notation, that is, <tt>products.name</tt>
@@ -370,11 +375,11 @@ To show columns of joined tables in the view table, the ActiveRecord model class
 to be specified, that corresponds to the joined table:
 
   <%= grid(@products_grid) do |g|
-    g.column :name => 'Product Name', :attribute => 'name' do |product|  # primary table
+    g.column name: 'Product Name', attribute: 'name' do |product|  # primary table
       link_to(product.name, product_path(product))
     end
 
-    g.column :name => 'Category', :attribute => 'name', :model => Category |product| # joined table
+    g.column name: 'Category', attribute: 'name', model: Category do |product| # joined table
       product.category.name
     end
   %>
@@ -382,72 +387,69 @@ to be specified, that corresponds to the joined table:
 Please note that the blockless definition of the column only works with columns from the main table
 and it won't work with columns with <tt>:model</tt>
 
-=== Joined associations referring to the same table
+== Joined associations referring to the same table
 
-In case there are two joined associations both referring to the same table,
-ActiveRecord constructs a query where
-the second join provides an alias for the joined table. To enable WiceGrid to order and
-filter by columns belonging to different associations
-but originating from the same table, set <tt>:table_alias</tt> to this alias:
+In case there are two joined associations both referring to the same table, ActiveRecord constructs
+a query where the second join provides an alias for the joined table. To enable WiceGrid to order
+and filter by columns belonging to different associations but originating from the same table, set
+<tt>:table_alias</tt> to this alias:
 
 Model:
 
    class Project < ActiveRecord::Base
-     belongs_to :customer, :class_name => 'Company'
-     belongs_to :supplier, :class_name => 'Company'
+     belongs_to :customer, class_name: 'Company'
+     belongs_to :supplier, class_name: 'Company'
    end
 
 Controller:
 
-    @projects_grid = initialize_grid(Project, :include => [:customer, :supplier] )
+    @projects_grid = initialize_grid(Project, include: [:customer, :supplier])
 
 
 View:
 
-  <%= grid(@projects_grid, :show_filters => :always) do |g|
+  <%= grid(@projects_grid, show_filters: :always) do |g|
 
-    g.column :name => 'Project Name', :attribute => 'name'
+    g.column name: 'Project Name', attribute: 'name'
 
-    g.column  :name => 'Customer company', :model => 'Company', :attribute => 'name' do |task|
+    g.column name: 'Customer company', model: 'Company', attribute: 'name' do |task|
       task.customer.name if task.customer
     end
 
-    g.column  :name => 'Supplier company', :model => 'Company', :attribute => 'name', :table_alias => ' suppliers_projects' do |task|
+    g.column name: 'Supplier company', model: 'Company', attribute: 'name', table_alias: 'suppliers_projects' do |task|
       task.supplier.name if task.supplier
     end
 
   end -%>
 
 
-=== More than one grid on a page
+== More than one grid on a page
 
-It is possible to use more that one grid on a page, each with its own state.
-To do so, you must specify the name of the grid in +initialize_grid+ using
-parameter <tt>:name</tt>
+It is possible to use more that one grid on a page, each with its own state. To do so, you must
+specify the name of the grid in +initialize_grid+ using parameter <tt>:name</tt>
 
-The name serves as the base name for HTTP parameters, DOM IDs, etc, so it
-is important that all grids on a page have different names. The default
-name is 'grid'.
+The name serves as the base name for HTTP parameters, DOM IDs, etc, so it is important that all
+grids on a page have different names. The default name is 'grid'.
 
 The name can only contain alphanumeric characters.
 
-  @projects_grid = initialize_grid(Project, :name => 'g1' )
-  @tasks_grid = initialize_grid(Task, :name => 'g2')
+  @projects_grid = initialize_grid(Project, name: 'g1')
+  @tasks_grid    = initialize_grid(Task,    name: 'g2')
 
 
-=== Custom Ordering
+== Custom Ordering
 
-It is possible to change the way results are ordered injecting a chunk of SQL code, for example, use
-<tt>ORDER BY INET_ATON(ip_address)</tt> instead of <tt>ORDER BY ip_address</tt>.
+It is possible to change the way results are ordered injecting a chunk of SQL code,
+for example, use <tt>ORDER BY INET_ATON(ip_address)</tt> instead of <tt>ORDER BY ip_address</tt>.
 
-To do so, provide parameter <tt>:custom_order</tt> in the initialization of the grid with a hash where keys are fully qualified names
-of database columns, and values the required chunks of SQL to use in the ORDER BY clause.
+To do so, provide parameter <tt>:custom_order</tt> in the initialization of the grid with
+a hash where keys are fully qualified names of database columns, and values the required chunks
+of SQL to use in the ORDER BY clause.
 
 For example:
 
-
   @hosts_grid = initialize_grid(Host,
-    :custom_order => {
+    custom_order: {
       'hosts.ip_address' => 'INET_ATON(hosts.ip_address)'
     })
 
@@ -455,23 +457,72 @@ For example:
 It is possible to use the '?' character instead of the name of the column in the hash value:
 
     @hosts_grid = initialize_grid(Host,
-      :custom_order => {
+      custom_order: {
         'hosts.ip_address' => 'INET_ATON( ? )'
       })
 
 Values can also be Proc objects. The parameter supplied to such a Proc object is the name of the column:
 
       @hosts_grid = initialize_grid(Host,
-        :custom_order => {
+        custom_order: {
           'hosts.ip_address' => lambda{|f| "INET_ATON( #{f} )"}
         })
 
+== Filters
+
+Each column filter type is supported by a <tt>column processor</tt>.
+Each <tt>column processor</tt> is responsible for
+
+* generating HTML and supporting Javascript for the filter, input fields, dropdowns, javascript calendars, etc
+* converting HTTP parameters from those input fields into ActiveRelation instances
+
+By default column filters depend on the type of the underlying database column.
+
+You can override these defaults in two ways:
+
+* defining a custom filter with <tt>:custom_filter</tt>. Read more about it section "Custom dropdown filters".
+* overriding the <tt>column processor</tt> type with <tt>:filter_type</tt>.
+
+Which Column Processor is instantiated for which data types is defined in file
+<tt>lib/wice/columns/column_processor_index.rb</tt>:
+
+
+  module Wice
+    module Columns
+      COLUMN_PROCESSOR_INDEX = ActiveSupport::OrderedHash[
+        :action   , 'column_action', # Special processor for action column, columns with checkboxes
+        :text     , 'column_string',
+        :string   , 'column_string',
+        :timestamp, 'column_datetime',
+        :datetime , 'column_datetime',
+        :date     , 'column_date',
+        :integer  , 'column_integer',
+        :range    , 'column_range',
+        :float    , 'column_float',
+        :decimal  , 'column_float',
+        :custom   , 'column_custom_dropdown',  # Special processor for custom filter columns
+        :boolean  , 'column_boolean'
+      ]
+    end
+  end
+
+A good example for using <tt>:filter_type</tt> to change th default is numeric columns.
+By default <tt>'column_integer'</tt> is instantiated for <tt>integer</tt> columns, and it
+renders one input field. But it is also possible to use another Column Processor called
+<tt>'column_range'</tt> which renders two input fields and searches for values in the given
+the range instead of searching for values which equal the given search term.
+
+It also possible to define and use your own column processors outside of the plugin, in
+you application. Read more about this in section "Defining your own external filter processors".
+
 
 === Custom dropdown filters
 
-It is possible to construct custom dropdown filters.
-Depending on the value of <tt>column</tt> parameter<tt>:custom_filter</tt> different
-modes are available:
+It is possible to construct custom dropdown filters. A custom dropdown filter
+is essentially a dropdown list.
+
+Depending on the value of
+<tt>column</tt> parameter<tt>:custom_filter</tt> different modes are available:
 
 
 ==== Array of two-element arrays or a hash
@@ -482,32 +533,26 @@ Every first item of the two-element array is used for the label of the select op
 element is the value of the select option. In case of a hash the keys become the labels
 of the generated dropdown list, while the values will be values of options of the dropdown list:
 
-  g.column :name => 'Status', :attribute => 'status',
-           :custom_filter => {'Development' => 'development', 'Testing' => 'testing', 'Production' => 'production'}
+  g.column name: 'Status', attribute: 'status',
+           custom_filter: {'Development' => 'development', 'Testing' => 'testing', 'Production' => 'production'}
 
-  g.column :name => 'Status', :attribute => 'status',
-          :custom_filter => [['Development', 'development'], ['Testing', 'testing'], ['Production', 'production']]
+  g.column name: 'Status', attribute: 'status',
+          custom_filter: [['Development', 'development'], ['Testing', 'testing'], ['Production', 'production']]
 
 It is also possible to submit a array of strings or numbers, in this case every item will be used
 both as the value of the select option and as its label:
 
-  g.column :name => 'Status', :attribute => 'status',
-           :custom_filter => ['development', 'testing', 'production']
+  g.column name: 'Status', attribute: 'status', custom_filter: ['development', 'testing', 'production']
 
 
 ==== :auto
 
 <tt>:auto</tt> - a powerful option which populates the dropdown list with all unique values of
-the column specified by
-<tt>:attribute</tt> and <tt>:model</tt>.
+the column specified by <tt>:attribute</tt> and <tt>:model</tt>, if present.
 
-  g.column :name => 'Status', :attribute => 'status',
-           :custom_filter => ['development', 'testing', 'production']
+  g.column name: 'Status', attribute: 'status', custom_filter: :auto
 
-Note that in the above example all names of all possible categories will appear even if they
-don't appear in the current resultset.
-To only show those which do appear in the resutset,
-use an array of symbol messages (see section 'An array of symbols').
+In the above example all statuses will appear in the dropdown even if they don't appear in the current resultset.
 
 
 ==== Custom filters and associations (joined tables)
@@ -518,26 +563,26 @@ To correctly build a filter condition foreign keys have to be used, not the actu
 
 For example, if there is a column:
 
-  g.column :name => 'Project Name', :attribute => 'name', :model => 'Project' do |task|
+  g.column name: 'Project Name', attribute: 'name', model: 'Project' do |task|
     task.project.name if task.project
   end
 
 adding <tt>:custom_filter</tt> like this:
 
-  g.column :name => 'Project Name', :attribute => 'name', :model => 'Project',
-           :custom_filter => Project.find(:all).map{|pr| [pr.name, pr.name]} do |task|
+  g.column name: 'Project Name', attribute: 'name', model: 'Project',
+           custom_filter: Project.find(:all).map{|pr| [pr.name, pr.name]} do |task|
     task.project.name if task.project
   end
 
 is bad style and can fail, because the resulting condition will compare the name of the project, <tt>projects.name</tt> to a string,
 and in some databases it is possible that different  records (projects in our example) have the same name.
 
-To use filter with foreign keys, we have to change the declaration of the column from <tt>projects.name</tt>, to
+To use filter with foreign keys, it is advised to change the declaration of the column from <tt>projects.name</tt>, to
 <tt>tasks.project_id</tt>, and build the dropdown with foreign keys as values:
 
 
-  g.column :name => 'Project Name', :attribute => 'tasks.project_id',
-           :custom_filter => Project.find(:all).map{|pr| [pr.id, pr.name]} do |task|
+  g.column name: 'Project Name', attribute: 'tasks.project_id',
+           custom_filter: Project.find(:all).map{|pr| [pr.id, pr.name]} do |task|
     task.project.name if task.project
   end
 
@@ -545,8 +590,8 @@ However, this will break the ordering of the column - the column will be ordered
 To fix this, we can override the ordering using <tt>:custom_order</tt>:
 
   @tasks_grid = initialize_grid(Task,
-    :include => :project,
-    :custom_order => {
+    include: :project,
+    custom_order: {
       'tasks.project_id' => 'projects.name'
     }
   )
@@ -555,9 +600,8 @@ To fix this, we can override the ordering using <tt>:custom_order</tt>:
 ==== Any other symbol (method name) or an array of symbols (method names)
 
 
-For one symbol (different from <tt>:auto</tt>) the dropdown list is populated by all
-unique values returned by the method with this name
-sent to <em>all</em> ActiveRecord objects throughout all pages.
+For one symbol (different from <tt>:auto</tt>) the dropdown list is populated by all unique values
+returned by the method with this name sent to <em>all</em> ActiveRecord objects throughout all pages.
 
 The conditions set up by the user are ignored, that is, the records used are all those found on
 all pages without any filters active.
@@ -567,7 +611,7 @@ object if it responds to this method, the second method name is sent to the
 returned value unless it is +nil+, and so on. In other words, a single symbol mode is the
 same as an array of symbols where the array contains just one element.
 
-  g.column :name => 'Version', :attribute => 'expected_version_id', :custom_filter => [:expected_version, :to_option] do |task|
+  g.column name: 'Version', attribute: 'expected_version_id', custom_filter: [:expected_version, :to_option] do |task|
     task.expected_version.name if task.expected_version
   end
 
@@ -599,7 +643,7 @@ Typically, a model method like the following:
 
 together with
 
-  :custom_filter => :to_option
+  custom_filter:  :to_option
 
 would do the trick:
 
@@ -615,8 +659,7 @@ and the key - for the value:
 
 ==== Special treatment of values 'null' and 'not null'
 
-Values 'null' and 'not null' in a generated custom filter are treated specially,
-as SQL +null+ statement and not as strings.
+Values 'null' and 'not null' in a generated custom filter are treated specially, as SQL +null+ statement and not as strings.
 Value 'null' is transformed into SQL condition <tt>IS NULL</tt>, and 'not null' into <tt>IS NOT NULL</tt>
 
 Thus, if in a filter defined by
@@ -632,28 +675,173 @@ By default it is possible for any dropdown list to switch between single and mul
 To only allow single selection use <tt>:allow_multiple_selection</tt>:
 
 
-  g.column :name => 'Expected in version', :attribute => 'expected_version_id',
-         :custom_filter => [:expected_version, :to_option], :allow_multiple_selection => false do |task|
+  g.column name: 'Expected in version', attribute: 'expected_version_id',
+         custom_filter: [:expected_version, :to_option], allow_multiple_selection: false do |task|
     ...
   end
 
 
-==== Numeric Filters
+=== Numeric Filters
 
 Before version 3.2.1 the filter used for numeric columns was a range filter with two limits. Beginning with version  3.2.1
 the default is a direct comparison filter with one input field. The old range filter can still be loaded using parameter <tt>:filter_type</tt>
 with value <tt>:range</tt>:
 
-  g.column :filter_type => :range do |task|
+  g.column filter_type: :range do |task|
     ...
   end
 
 
-=== Defaults
+=== Javascript Calendar for Date and DateTime Filters.
+
+WiceGrid uses jQuery datepicker[http://jqueryui.com/demos/datepicker/] for Date and DateTime filters by default.
+Because this is part of the standard jQuery codebase, it is not bundled together with the plugin,
+and it is the responsibility of the programmer to include all necessary assets including
+localization files if the application is multilingual.
+
+
+jQuery datepicker does not have any time related controls, and when dealing with DateTime filters, the time value is ignored.
+
+Another option is standard Rails helpers. It's possible to change between the two styles of Date/DateTime
+filters in <tt>config/initializers/wice_grid_config.rb</tt> using constant HELPER_STYLE, or set it on per-column basis:
+
+  g.column name: 'Due Date', attribute: 'due_date', helper_style: :calendar do |task|
+    task.due_date.to_s(:short) if task.due_date
+  end
+
+  g.column name: 'Updated', attribute: 'updated_at', helper_style: :standard do |task|
+    task.created_at.to_s(:short)
+  end
+
+Constants +DATE_FORMAT+ and +DATETIME_FORMAT+ in the configuration file define the format of dates the user will see, as well as the
+format of the string sent in a HTTP parameter. If you change the formats,  make sure that lamdbas defined
+in +DATETIME_PARSER+ and +DATE_PARSER+ return valid DateTime and Date objects.
+
+jQuery +datepicker+ uses a different format flavor, therefore there is an additional constant
++DATE_FORMAT_JQUERY+. While +DATE_FORMAT_JQUERY+ is fed to +datepicker+, +DATE_FORMAT+ is still used
+for presenting initial date values in filters, so make sure that +DATE_FORMAT_JQUERY+ and +DATE_FORMAT+
+result in an identical date representation.
+
+Constant +DATEPICKER_YEAR_RANGE+ defined the range of years in the Datepicker year dropdown. Alternatively,
+you can always change this range dynamically with the following javascript:
+
+  $( ".hasDatepicker" ).datepicker( "option", "yearRange", "2000:2042" );
+
+
+
+== Detached Filters
+
+Filters can also be detached from the grid table and placed anywhere on page.
+
+This is a 3-step process.
+
+First, define the grid with helper +define_grid+ instead of +grid+.
+Everything should be done the same way as with +grid+, but every column which will have an external filter,
+add <tt>detach_with_id: :some_filter_name+</tt> in the column definition. The value of +:detach_with_id+ is an arbitrary string
+or a symbol value which will be used later to identify the filter.
+
+  <%= define_grid(@tasks_grid, show_filters: :always) do |g|
+
+    g.column name: 'Title', attribute: 'title', detach_with_id: :title_filter do |task|
+      link_to('Edit', edit_task_path(task.title))
+    end
+
+    g.column name: 'Archived', attribute: 'archived', detach_with_id: :archived_filter do |task|
+      task.archived? ? 'Yes' : 'No'
+    end
+
+    g.column name: 'Added', attribute: 'created_at', detach_with_id: :created_at_filter do |task|
+      task.created_at.to_s(:short)
+    end
+
+  end -%>
+
+
+Then, use <tt>grid_filter(grid, :some_filter_name)</tt> to render filters:
+
+  <% # rendering filter with key :title_filter %>
+  <%= grid_filter @tasks_grid, :title_filter  %>
+
+  <% # rendering filter with key :archived_filter %>
+  <%= grid_filter @tasks_grid, :archived_filter  %>
+
+  <% # rendering filter with key :created_at_filter %>
+  <%= grid_filter @tasks_grid, :created_at_filter  %>
+
+  <% # Rendering the grid body %>
+  <%= grid(@tasks_grid) %>
+
+
+Finally, use <tt>render_grid(@grid)</tt> to actually output the grid table .
+
+
+Using custom submit and reset buttons together with <tt>:hide_submit_button => true</tt>
+and <tt>:hide_reset_button => true</tt> allows to completely get rid
+of the default filter row and the default icons (see section 'Submit/Reset Buttons').
+
+
+If a column was declared with <tt>:detach_with_id</tt>, but never output with +grid_filter+,
+filtering the grid in development mode will result in an warning javascript message and the missing filter will be ignored.
+There is no such message in production.
+
+
+=== Defining your own external filter processors
+
+
+It possible to define and use your own column processors outside of the plugin, in
+you application.
+
+The first step is to edit <tt>Wice::Defaults::ADDITIONAL_COLUMN_PROCESSORS</tt> in
+<tt>wice_grid_config.rb</tt>:
+
+
+  Wice::Defaults::ADDITIONAL_COLUMN_PROCESSORS = {
+    my_own_filter:    ['ViewColumnMyOwnFilter',   'ConditionsGeneratorMyOwnFilter'],
+    another_filter:   ['ViewColumnAnotherFilter', 'ConditionsGeneratorAnotherFilter']
+  }
+
+The first element in the two-item array is the name of a class responsible for rendering
+the filter view. The second element  is the name of a class responsible for processing
+filter parameters.
+
+For examples of these two classes look at the existing column processors in <tt>lib/wice/columns/</tt>
+
+The structure of these two classes is as follows:
+
+  class ViewColumnMyOwnFilter < Wice::Columns::ViewColumn
+
+    def render_filter_internal(params)
+      ...
+    end
+
+    def yield_declaration_of_column_filter
+      {
+        :templates => [...],
+        :ids       => [...]
+      }
+    end
+  end
+
+
+  class ConditionsGeneratorMyOwnFilter < Wice::Columns::ConditionsGeneratorColumn
+
+    def generate_conditions(table_name, opts)
+      ...
+    end
+
+  end
+
+To use an external column processor use <tt>:filter_type</tt> in a column definition:
+
+  column name: 'name', attribute: 'attribute', filter_type: :my_own_filter do |rec|
+    ...
+  end
+
+== Defaults
 
 Default values like  can be  changed in <tt>config/initializers/wice_grid_config.rb</tt>.
 
-=== Submit/Reset buttons
+== Submit/Reset buttons
 Instead of using default Submit and Reset icons you can use external HTML elements to trigger
 these actions. Add a button or any other clickable HTML element with class
 +wg-external-submit-button+ or +wg-external-reset-button+, and attribute +data-grid-name+
@@ -668,7 +856,7 @@ To hide the default icons use <tt>:hide_submit_button => true</tt> and
 
 
 
-=== Auto-reloading filters
+== Auto-reloading filters
 
 It is possible to configure a grid to reload itself once a filter has been changed. It works with all
 filter types including the JS calendar, the only exception is the standard Rails date/datetime filters.
@@ -676,21 +864,21 @@ filter types including the JS calendar, the only exception is the standard Rails
 Use option <tt>:auto_reload</tt> in the column definiton:
 
 
-  <%= grid(@tasks_grid, :show_filters => :always, :hide_submit_button => true) do |g|
+  <%= grid(@tasks_grid, show_filters: :always, hide_submit_button: true) do |g|
 
     # String
-    g.column :name => 'Title', :attribute => 'title', :auto_reload => true
+    g.column name: 'Title', attribute: 'title', auto_reload: true
 
     # Boolean
-    g.column :name => 'Archived', :attribute => 'archived', :auto_reload => true
+    g.column name: 'Archived', attribute: 'archived', auto_reload: true
 
     # Custom (dropdown)
-    g.column :name => 'Status', :attribute => 'status_id', :custom_filter => Status.to_dropdown, :auto_reload => true  do |task|
+    g.column name: 'Status', attribute: 'status_id', custom_filter: Status.to_dropdown, auto_reload: true  do |task|
       task.status.name if task.status
     end
 
     # Datetime
-    g.column :name => 'Added', :attribute => 'created_at', :auto_reload => true, :helper_style => :calendar do |task|
+    g.column name: 'Added', attribute: 'created_at', auto_reload: true, helper_style: :calendar do |task|
       task.created_at.to_s(:short)
     end
 
@@ -698,23 +886,21 @@ Use option <tt>:auto_reload</tt> in the column definiton:
 
 To make this  behavior default change constant +AUTO_RELOAD+ in the configuration file.
 
-=== Styling the grid
+== Styling the grid
 
 
-==== Adding classes and styles
+=== Adding classes and styles
 
-The +grid+ helper accepts parameter <tt>:html</tt> which is a hash of HTML
-attributes for the table tag.
+The +grid+ helper accepts parameter <tt>:html</tt> which is a hash of HTML attributes for the table tag.
 
 Another +grid+ parameter is <tt>header_tr_html</tt> which is a hash of HTML attributes to
 be added to the first +tr+ tag (or two first +tr+'s if the filter row is present).
 
 <tt>:html</tt> is a parameter for the +column+ method setting HTML attributes of +td+ tags for a certain column.
 
-==== Adding classes and styles dynamically
+=== Adding classes and styles dynamically
 
-WiceGrid offers ways to dynamically add classes and styles to +TR+ and +TD+
-based on the current ActiveRecord instance.
+WiceGrid offers ways to dynamically add classes and styles to +TR+ and +TD+ based on the current ActiveRecord instance.
 
 
 For <tt><TD></tt>, let the +column+ return an array where the first item is the usual
@@ -745,7 +931,7 @@ Naturally, there can be only one +row_attributes+ definition for a WiceGrid inst
 Various classes do not overwrite each other, instead, they are concatenated.
 
 
-=== Adding rows to the grid
+== Adding rows to the grid
 
 It is possible to add your own handcrafted HTML after and/or before each grid row.
 This works similar to +row_attributes+, by adding blocks +after_row+, +before_row+,  and +last_row+:
@@ -771,15 +957,13 @@ This works similar to +row_attributes+, by adding blocks +after_row+, +before_ro
     .......
   end %>
 
-It is up for the developer to return the correct HTML code, or
-return +nil+ if no row is needed for this record.
-Naturally, there is only one +before_row+  definition and one +after_row+
-definition for a WiceGrid instance.
+It is up for the developer to return the correct HTML code, or return +nil+ if no row is needed for this record.
+Naturally, there is only one +before_row+  definition and one +after_row+ definition for a WiceGrid instance.
 
 The second variable injected into to <tt>before_row</tt> and <tt>after_row</tt> block, and the first parameter injected
 into the <tt>last_row</tt> is the number of columns in the current grid.
 
-=== Rendering a grid without records
+== Rendering a grid without records
 
 If the grid does not contain any records to show, it is possible show some alternative view instead of
 an empty grid. Bear in mind that if the user sets up the filters in such a way that the selection of
@@ -806,7 +990,7 @@ Or a partial:
   g.blank_slate :partial => "partial_name"
 
 
-=== Action Column
+== Action Column
 
 It is possible to add a column with checkboxes for each record. This is useful for actions with multiple records,
 for example, deleting selected records. Please note that +action_column+ only creates the checkboxes and the
@@ -848,18 +1032,16 @@ WiceGrid is form-friendly: submitting grid in a form retains the state of the fo
 
 
 
-=== Integration of the grid with other forms on page
+== Integration of the grid with other forms on page
 
 Imagine that the user should be able to change the behavior of the grid using some other control
 on the page, and not a grid filter.
 
-For example, on a page showing tasks,
-change between 'Show active tasks' to 'Show archived tasks' using a dropdown box.
-WiceGrid allows to keep the status of the grid with all the filtering and sorting
-using helper +dump_filter_parameters_as_hidden_fields+ which takes a grid object and dumps
-all current sorting and filtering parameters as
-hidden fields. Just include <tt>dump_filter_parameters_as_hidden_fields(@grid)</tt> inside your form,
-and the newly rendered grid will keep ordering and filtering.
+For example, on a page showing tasks, change between 'Show active tasks' to 'Show archived tasks' using a dropdown box.
+WiceGrid allows to keep the status of the grid with all the filtering and sorting using helper
++dump_filter_parameters_as_hidden_fields+ which takes a grid object and dumps
+all current sorting and filtering parameters as hidden fields. Just include
+<tt>dump_filter_parameters_as_hidden_fields(@grid)</tt> inside your form, and the newly rendered grid will keep ordering and filtering.
 
   <% form_tag('', :method => :get) do %>
     <%= dump_filter_parameters_as_hidden_fields(@tasks_grid) %>
@@ -869,45 +1051,8 @@ and the newly rendered grid will keep ordering and filtering.
   <% end -%>
 
 
-=== Javascript Calendar for Date and DateTime Filters.
 
-WiceGrid uses jQuery datepicker[http://jqueryui.com/demos/datepicker/] for Date and DateTime filters
-by default.
-Because this is part of the standard jQuery codebase, it is not bundled together with the plugin,
-and it is the responsibility of the programmer to include all necessary assets including
-localization files if the application is multilingual.
-
-
-jQuery datepicker does not have any time related controls, and when dealing with DateTime filters,
-the time value is ignored.
-
-Another option is standard Rails helpers. It's possible to change between the two styles of Date/DateTime
-filters in <tt>config/initializers/wice_grid_config.rb</tt> using constant HELPER_STYLE, or set it on per-column basis:
-
-  g.column :name => 'Due Date', :attribute => 'due_date', :helper_style => :calendar do |task|
-    task.due_date.to_s(:short) if task.due_date
-  end
-
-  g.column :name => 'Updated', :attribute => 'updated_at', :helper_style => :standard do |task|
-    task.created_at.to_s(:short)
-  end
-
-Constants +DATE_FORMAT+ and +DATETIME_FORMAT+ in the configuration file define the format of dates the user will see, as well as the
-format of the string sent in a HTTP parameter. If you change the formats,  make sure that lamdbas defined
-in +DATETIME_PARSER+ and +DATE_PARSER+ return valid DateTime and Date objects.
-
-jQuery +datepicker+ uses a different format flavor, therefore there is an additional constant
-+DATE_FORMAT_JQUERY+. While +DATE_FORMAT_JQUERY+ is fed to +datepicker+, +DATE_FORMAT+ is still used
-for presenting initial date values in filters, so make sure that +DATE_FORMAT_JQUERY+ and +DATE_FORMAT+
-result in an identical date representation.
-
-Constant +DATEPICKER_YEAR_RANGE+ defined the range of years in the Datepicker year dropdown. Alternatively,
-you can always change this range dynamically with the following javascript:
-
-  $( ".hasDatepicker" ).datepicker( "option", "yearRange", "2000:2042" );
-
-
-=== Show All Records
+== Show All Records
 
 It is possible to switch to the All Records mode clicking on link "show all" in the bottom right corner.
 This functionality should be used with care. To turn this mode off for all grid instances,
@@ -918,7 +1063,7 @@ Configuration constant +START_SHOWING_WARNING_FROM+ sets the threshold number of
 which clicking on the link results in a javascript confirmation dialog.
 
 
-=== CSV Export
+== CSV Export
 
 It is possible to export the data displayed on a grid to a CSV file. The dumped data is the current resultset
 with all the current filters and sorting applied, only without the pagination constraint (i.e. all pages).
@@ -926,10 +1071,10 @@ with all the current filters and sorting applied, only without the pagination co
 To enable CSV export add parameters +enable_export_to_csv+ and +csv_file_name+ to the initialization of the grid:
 
   @projects_grid = initialize_grid(Project,
-    :include => [:customer, :supplier],
-    :name => 'g2',
-    :enable_export_to_csv => true,
-    :csv_file_name => 'projects'
+    include:              [:customer, :supplier],
+    name:                 'g2',
+    enable_export_to_csv: true,
+    csv_file_name:        'projects'
   )
 
 +csv_file_name+ is the name of the downloaded file. This parameter is optional, if it is missing, the name of
@@ -967,15 +1112,15 @@ as the last line of the action:
   def index
 
     @tasks_grid = initialize_grid(Task,
-      :name => 'g1',
-      :enable_export_to_csv => true,
-      :csv_file_name => 'tasks'
+      name:                 'g1',
+      enable_export_to_csv: true,
+      csv_file_name:        'tasks'
     )
 
     @projects_grid = initialize_grid(Project,
-      :name => 'g2',
-      :enable_export_to_csv => true,
-      :csv_file_name => 'projects'
+      name:                 'g2',
+      enable_export_to_csv: true,
+      csv_file_name:        'projects'
     )
 
     export_grid_if_requested
@@ -989,7 +1134,7 @@ Otherwise, to avoid double rendering, use the return value of the method to cond
 
     ...........
 
-    export_grid_if_requested || render(:action => 'my_template')
+    export_grid_if_requested || render(action: 'my_template')
   end
 
 
@@ -1000,7 +1145,7 @@ It's also possible to supply a block which will be called if no CSV export is re
     ...........
 
     export_grid_if_requested do
-       render(:action => 'my_template')
+       render(action: 'my_template')
     end
   end
 
@@ -1008,105 +1153,45 @@ It's also possible to supply a block which will be called if no CSV export is re
 If a column has to be excluded from the CSV export,
 set +column+ parameter +in_csv+ to +false+:
 
-  g.column  :in_csv => false do |task|
+  g.column in_csv: false do |task|
     link_to('Edit', edit_task_path(task))
   end
 
-If a column must appear both in HTML and CSV, but with different output,
-duplicate the column and use
+If a column must appear both in HTML and CSV, but with different output, duplicate the column and use
 parameters +in_csv+ and +in_html+ to include one of them to  html output only, the other to CSV only:
 
 
   # html version
-  g.column :name => 'Title', :attribute => 'title', :in_csv => false do |task|
+  g.column name: 'Title', attribute: 'title', in_csv: false do |task|
     link_to('Edit', edit_task_path(task.title))
   end
   # plain text version
-  g.column :name => 'Title', :in_html => false do |task|
+  g.column name: 'Title', in_html: false do |task|
     task.title
   end
 
 The default field separator in generated CSV is a comma, but it's possible to override it:
 
   @products_grid = initialize_grid(Product,
-    :enable_export_to_csv => true,
-    :csv_field_separator => ';',
-    :csv_file_name => 'products')
+    enable_export_to_csv:  true,
+    csv_field_separator:   ';',
+    csv_file_name:         'products'
+  )
 
 If you need an external CSV export button , add class +wg-external-csv-export-button+
-to any clickable element on page and set its attribute +data-grid-name+ to the name of
-the grid:
+to any clickable element on page and set its attribute +data-grid-name+ to the name of the grid:
 
       <button class="wg-external-csv-export-button" data-grid-name="grid">Export To CSV</button>
 
-If you need to disable the default export icon in the grid, add
-<tt>:hide_csv_button => true</tt> to the +grid+ helper.
-
-=== Detached Filters
-
-Filters can also be detached from the grid table and placed anywhere on page.
-
-This is a 3-step process.
-
-First, define the grid with helper +define_grid+ instead of +grid+.
-Everything should be done the same way as with +grid+, but every column which will have an external filter,
-add <tt>:detach_with_id => :some_filter_name+</tt> in the column definition. The value of +:detach_with_id+ is an arbitrary string
-or a symbol value which will be used later to identify the filter.
-
-  <%= define_grid(@tasks_grid, :show_filters => :always) do |g|
-
-    g.column :name => 'Title', :attribute => 'title', :detach_with_id => :title_filter do |task|
-      link_to('Edit', edit_task_path(task.title))
-    end
-
-    g.column  :name => 'Archived', :attribute => 'archived', :detach_with_id => :archived_filter do |task|
-      task.archived? ? 'Yes' : 'No'
-    end
-
-    g.column :name => 'Added', :attribute => 'created_at', :detach_with_id => :created_at_filter do |task|
-      task.created_at.to_s(:short)
-    end
-
-  end -%>
-
-
-Then, use <tt>grid_filter(grid, :some_filter_name)</tt> to render filters:
-
-  <% # rendering filter with key :title_filter %>
-  <%= grid_filter @tasks_grid, :title_filter  %>
-
-  <% # rendering filter with key :archived_filter %>
-  <%= grid_filter @tasks_grid, :archived_filter  %>
+If you need to disable the default export icon in the grid, add <tt>hide_csv_button: true</tt> to the +grid+ helper.
 
-  <% # rendering filter with key :created_at_filter %>
-  <%= grid_filter @tasks_grid, :created_at_filter  %>
 
-  <% # Rendering the grid body %>
-  <%= grid(@tasks_grid) %>
-
-
-Finally, use <tt>render_grid(@grid)</tt> to actually output the grid table .
-
-
-Using custom submit and reset buttons together with <tt>:hide_submit_button => true</tt>
-and <tt>:hide_reset_button => true</tt>
-allows to completely get rid
-of the default filter row and the default icons (see section 'Submit/Reset Buttons').
-
-
-If a column was declared with <tt>:detach_with_id</tt>, but never output with +grid_filter+,
-filtering the grid in development mode will result
-in an warning javascript message and the missing filter will be ignored.
-There is no such message in production.
-
-
-
-=== Access to Records From Outside The Grid
+== Access to Records From Outside The Grid
 
 There are two ways you can access the records outside the grid - using methods of the WiceGrid
 object and using callbacks.
 
-==== Accessing Records Via The WiceGrid Object
+=== Accessing Records Via The WiceGrid Object
 
 Method +current_page_records+ returns exactly the same list of objects displayed on page:
 
@@ -1139,7 +1224,7 @@ This is due to the lazy nature of WiceGrid - the actual call to the database is
 the execution of
 the +grid+ helper, because to build the correct query columns declarations are required.
 
-==== Accessing Records Via Callbacks
+=== Accessing Records Via Callbacks
 
 It is possible to set up callbacks which are executed from within the plugin just after the call to the database.
 The callbacks are called before rendering the grid cells, so the results of this processing can be used in the grid.
@@ -1149,9 +1234,9 @@ Via a lambda object:
 
   def index
     @tasks_grid = initialize_grid(Task,
-      :with_paginated_resultset => lambda do |records|
+      with_paginated_resultset: ->(records){
         ...
-      end
+      }
     )
   end
 
@@ -1159,7 +1244,7 @@ Via a symbol which is the name of a controller method:
 
   def index
     @tasks_grid = initialize_grid(Task,
-      :with_paginated_resultset => :process_selection
+      with_paginated_resultset: :process_selection
     )
   end
 
@@ -1190,7 +1275,7 @@ receives an ActiveRelation object which can be used to obtain the list of all re
     @tasks_grid = initialize_grid(Task)
 
     @tasks_grid.with_resultset do |active_relation|
-      all_records = active_relation.find(:first)
+      all_records = active_relation.all
       ...
     end
   end
@@ -1203,9 +1288,9 @@ only under certain circumstances:
   def index
     @tasks_grid = initialize_grid(Task)
 
-    @tasks_grid.with_resultset do |wrapper|
+    @tasks_grid.with_resultset do |active_relation|
       if params[:process_all_records]
-        all_records = wrapper.call
+        all_records = active_relation.all
         ...
       end
     end