wice_grid 3.4.14 → 3.5.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: eb195130076e0d26e2e998942a00bb1ded5e4c18
-  data.tar.gz: bca19e8e2f79279d8264b64edb4f40ddb28f9d2e
+  metadata.gz: adffa454db1aaf48823d131bb5069b8ca23dcbad
+  data.tar.gz: 75d831e4513a585cfcf1900bf3b84fb68d445c9e
 SHA512:
-  metadata.gz: 49cb6b35bd7b45a7e5b90ba6f6fa9377c9e85ef6c9b362eebbb9eb9b0ca1331aaff574f3051a5f580924523600e24bde5a7a1b99e7050d84dc14c4164ddb89cb
-  data.tar.gz: 0fc5ef95c9a5f96bc41a59c421fe73bbf44040fc7bdadfa99f3b4085d2e84ee4f7887458e877e7acfd6f36561e86d5dcf6836979d2a4967f5e8592d287070872
+  metadata.gz: 22ba98f7d7dc809b16ecb599b14ba96a09a3e6d55eb4d70ef6b14a68a1cc86f0e0cb11712facf429c6a5b562536ead818c5fd06fb38566ffdaf33a091ed24fe9
+  data.tar.gz: bcb4e05fa26aa09d0f4576ca4240b9646cdf354b702267645d815cf02eb634fb127c7bbd417872c2aea8742a2f5a060ecef6b6625d58ef05d036f25d84853531

data/.gitignore

@@ -2,6 +2,7 @@
 *.rbc
 .bundle
 .config
+.idea
 .yardoc
 .rbenv-version
 Gemfile.lock

data/CHANGELOG

@@ -1,3 +1,41 @@
+3.5.0
+
+New features:
+
+* In addition to two icons "SET ALL" and "UNSET ALL" in the action column, there is now
+  an option to use a standard HTML checkbox. This is now the default.
+* Support for Bootstrap Datepicker. A suggested way to use Bootstrap Datepicker in a Rails app
+  is https://github.com/Nerian/bootstrap-datepicker-rails. Configuration variable HELPER_STYLE
+  sets the default flavor of date pickers.
+
+  * :calendar  jQuery UI datepicker
+  * :bootstrap Bootstrap datepicker
+  * :standard
+* Italian locale
+* Spanish locale
+* various fixes
+* Configuration variable ALLOW_SHOWING_ALL_QUERIES renamed to ALLOW_SHOWING_ALL_RECORDS
+
+Can also be set per grid with helper_style: :bootstrap
+
+3.4.14
+
+Wice::Defaults::HIDE_ALL_LINK_FROM is nil by default
+
+3.4.13
+
+New configuration variable Wice::Defaults::HIDE_ALL_LINK_FROM! When set and the total
+number of row exceeds its value, the "SHOW ALL" link disappears.
+
+3.4.12
+
+fixes
+
+3.4.11
+
+started adding HTML5 datepicker
+changed how relations are detected so that it can work with relation proxies (aka octopus)
+
 3.4.10
 
 bug fixes

data/README.rdoc

@@ -1,100 +1,98 @@
 = WiceGrid
 
-Version:: 3.4.11
+Version:: 3.5.0
 Author::  Yuri Leikind
 Sources:: https://github.com/leikind/wice_grid/
 Examples online:: http://wicegrid.herokuapp.com
-News:: http://leikind.org/tag/wicegrid/
 Email::   "Yuri Leikind" <yuri.leikind at gmail dot com>
 
 
-The main supported branch is +rails3+. Rails 3 and Rails 4 are supported.
-
-For rails 2 use the +master+ branch:  https://github.com/leikind/wice_grid/tree/master
-
 
 == Intro
 
 WiceGrid is a Rails grid plugin.
 
-One of the goals of this plugin was to allow the programmer to define the contents of the cell by himself,
-just like one does when rendering a collection via a simple table (and this is what differentiates WiceGrid
-from various scaffolding solutions), but automate implementation of filters, ordering, paginations,
-CSV export, and so on. Ruby blocks provide an elegant means for this.
+One of the goals of this plugin was to allow the programmer to define the contents of the cell on their
+own, just like one does when rendering a collection via a simple table (and this is what differentiates
+WiceGrid from various scaffolding solutions), but automate implementation of filters, ordering,
+paginations, CSV export, and so on. Ruby blocks provide an elegant means for this.
 
 
 WiceGrid builds the call to the ActiveRecord layer for you and creates a table view with the results
 of the call including:
 
-* paging
+* pagination
 * sortable columns
 * filtering by multiple columns
 * CSV export
-* saving queries
+* saved queries
 
-All working nicely together. Filters are added automatically according to the type of the underlying DB column.
-Filtering by more than one column at the same time is possible.
-More than one such grid can appear on a page, and manipulations with one grid do not have any impact on the other.
+Filters are added automatically according to the type of the underlying DB column. Filtering by more
+than one column at the same time is possible. More than one such grid can appear on a page, and
+manipulations with one grid do not have any impact on others.
 
 WiceGrid does not take a collection as an input, it works directly with ActiveRecord.
 
-WiceGrid does not use AJAX calls to reload itself, instead simple GET requests are used for this,
-nevertheless, all other page parameters are respected and preserved.
+WiceGrid does not use XHR calls to reload itself, instead simple GET requests are used for this,
+nevertheless, all other page parameters are respected and preserved. WiceGrid works well with Turbolinks.
+
 WiceGrid views do not contain forms so you can include it in your own forms.
 
 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.
+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.
 
 
-== Requirements
 
-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).
+== Requirements and Rails versions
 
-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>!
+For rails 2 use version 0.6 in {the master branch}[https://github.com/leikind/wice_grid/tree/master].
+That branch is hardly supported.
 
+The main supported branch is +rails3+. Latest Rails 3.2.x and Rails 4.x.x are supported in this branch.
 
+If you need to use the plugin in with Rails 3.0.x and 3.1.x versions, please use WiceGrid version 3.0.4.
 
+WiceGrid relies on jQuery.
 
-== Support for javascript frameworks
+If you need a JS Datepicker, WiceGrid supports jQuery Datepicker or
+{Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails], so you might need one of
+those. See section Installation for details on how to use datepickers.
 
-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.
+WARNING: Since 3.2.pre2 WiceGrid is not compatible with +will_paginate+ because internally it uses
++kaminari+ for pagination, and +kaminari+ is not compatible with +will_paginate+!
 
 
 == Installation
 
 Add the following to your Gemfile:
 
-  gem "wice_grid", '3.4.2'
+  gem "wice_grid", '3.5.0'
 
-and run the <tt>bundle</tt> command.
+and run the +bundle+ command.
 
 Run the generator:
 
    rails g wice_grid:install
 
 This adds the config file <tt>wice_grid_config.rb</tt> to <tt>config/initializers/</tt>, the locale file
-<tt>wice_grid.yml</tt> to <tt>config/locales/</tt>, and the styles file
-<tt>wice_grid.css.scss</tt> to <tt>app/assets/stylesheets/</tt>.
+<tt>wice_grid.yml</tt> to <tt>config/locales/</tt>, and the styles file <tt>wice_grid.scss</tt> to
+<tt>app/assets/stylesheets/</tt>.
 
 Require WiceGrid javascript in your js index file:
 
   //= require wice_grid
 
-Make sure that jQuery is loaded.
-If the application uses Date and DateTime filters, you have to install jQuery Datepicker by yourself.
-
-Here is an example of application.js with everything WiceGrid needs:
+Make sure jQuery is loaded. If the application uses Date and DateTime filters, you have to install
+jQuery Datepicker by yourself. You can also use
+{Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails].
 
+Here is an example of +application.js+ if jquery.ui.datepicker is used:
   //= require jquery
   //= require jquery_ujs
   //= require jquery-ui
@@ -102,9 +100,17 @@ Here is an example of application.js with everything WiceGrid needs:
   //= require jquery.ui.datepicker
   //= require_tree .
 
-WiceGrid provides some very basic styles, not specifying exactly how the table should look like,
-but if the application uses Twitter Bootstrap, the markup generated by WiceGrid will have correct classes and will fit nicely.
-Generally it is advised to modify WiceGrid css to match the application style.
+Here is +application.js+ if {Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails] is used:
+  //= require jquery
+  //= require jquery_ujs
+  //= require jquery-ui
+  //= require wice_grid
+  //= require bootstrap-datepicker
+  //= require_tree .
+
+WiceGrid provides some very basic styles, not specifying exactly how the table should look like, but if
+the application uses Twitter Bootstrap, the markup generated by WiceGrid will have correct classes and
+will fit nicely. Generally it is advised to modify WiceGrid css to match the application style.
 
 
 == Basics
@@ -117,7 +123,7 @@ Controller:
 
 It is also possible to use an  ActiveRecord::Relation instance as the first argument:
 
-  @tasks_grid = initialize_grid(Task.where(:active => true))
+  @tasks_grid = initialize_grid(Task.where(active: true))
 
 View:
 
@@ -146,10 +152,9 @@ View:
 
 Code <tt>g.column do |task| ... end</tt>
 defines everything related to a column in the resulting view table including column names, sorting,
-filtering, the content of the column cells, etc.
-The return value of the block is the table cell content.
+filtering, the content of the column cells, etc. The return value of the block is the table cell content.
 
-Column names are defined with parameter <tt>:name</tt>:
+Column names are defined with parameter +:name+:
 
   <%= grid(@tasks_grid) do |g|
 
@@ -174,8 +179,8 @@ Column names are defined with parameter <tt>:name</tt>:
     end
   end -%>
 
-To add filtering and ordering, declare to which column in the underlying database
-table(s) the view column corresponds using parameter <tt>:attribute</tt> :
+To add filtering and ordering, declare to which column in the underlying database table(s) the view
+column corresponds using parameter +:attribute+:
 
   <%= grid(@tasks_grid) do |g|
 
@@ -200,31 +205,28 @@ table(s) the view column corresponds using parameter <tt>:attribute</tt> :
     end
   end -%>
 
-This will  add sorting links and filters for columns +Username+ and +Active+.
-The plugin automatically creates filters according to the type
-of the database column. In the above example a text field will be created for column Title (title is a string),
-for column +Archived+ a dropdown filter will be created with options 'Yes', 'No', and '--',
-and for the integer ID two short text fields are
-added which can contain the numeric range (more than, less than).
+This will  add sorting links and filters for columns +Username+ and +Active+. The plugin automatically
+creates filters according to the type of the database column. In the above example a text field will be
+created for column Title (title is a string), for column +Archived+ a dropdown filter will be created
+with options 'Yes', 'No', and '--', and for the integer ID two short text fields are added which can
+contain the numeric range (more than, less than).
 
-It is important to remember that <tt>:attribute</tt> is the name of the database column,
-not a model attribute.
-Of course, all database columns have corresponding model attributes,
-but not all model attributes map to columns in the same table with the same name.
+It is important to remember that +:attribute+ is the name of the database column, not a model attribute.
+Of course, all database columns have corresponding model attributes, but not all model attributes map to
+columns in the same table with the same name.
 
-Read more about available filters in the documentation
-for the column method.
+Read more about available filters in the documentation for the column method.
 
 Read the section about custom dropdown filters for more advanced filters.
 
-
 For columns like
 
   g.column name: 'Title', attribute: 'title'  do |task|
     task.title
   end
 
-where the block contains just a call to the same attribute declared by :attribute, the block can be omitted:
+where the block contains just a call to the same attribute declared by :attribute, the block can be
+omitted:
 
   <%= grid(@tasks_grid) do |g|
 
@@ -246,7 +248,7 @@ where the block contains just a call to the same attribute declared by :attribut
 
 In this case +name+ will be used as the method name to send to the ActiveRecord instance.
 
-If only ordering is needed, and no filter, we can turn off filters using <tt>:filter</tt> :
+If only ordering is needed, and no filter, we can turn off filters using +:filter+ :
 
   g.column name: 'ID', attribute: 'id', filter: false
 
@@ -254,9 +256,9 @@ If no ordering links are needed, use <tt>ordering: false</tt>:
 
   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).
+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
++:attribute+ (and +:model+ discussed below).
 
 
 == Rendering filter panel
@@ -264,12 +266,12 @@ column specified by  <tt>:attribute</tt> (and <tt>:model</tt> discussed below).
 The filter panel can be shown and hidden clicking the icon with binoculars.
 
 The way the filter panel is shown after the page is loaded is controlled via parameter
-<tt>:show_filters</tt> of the <tt>grid</tt> helper.
++:show_filters+ of the +grid+ helper.
 Possible values are:
 
-* <tt>:when_filtered</tt> - the filter is shown when the current table is the result of filtering
-* <tt>:always</tt> - always show the filter
-* <tt>:no</tt> - never show the filter
+* +:when_filtered+ - the filter is shown when the current table is the result of filtering
+* +:always+ - always show the filter
+* +:no+ - never show the filter
 
 Example:
 
@@ -278,17 +280,17 @@ Example:
   end -%>
 
 
-Filter related icons (filter icon, reset icon, show/hide icon) are placed in the header of the last column if
-it doesn't have any filter or a column name, otherwise an additional table column is added. To always place
-the icons in the additional column, set <tt>Wice::Defaults::REUSE_LAST_COLUMN_FOR_FILTER_ICONS</tt> to +false+ in
-the configuration file.
+Filter related icons (filter icon, reset icon, show/hide icon) are placed in the header of the last
+column if it doesn't have any filter or a column name, otherwise an additional table column is added.
+To always place the icons in the additional column, set
+<tt>Wice::Defaults::REUSE_LAST_COLUMN_FOR_FILTER_ICONS</tt> to +false+ in the configuration file.
 
 
 == 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:
+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',
@@ -297,14 +299,14 @@ setting by clicking the column label, and the order direction:
 
 == Records Per Page
 
-The number of rows per page is set with <tt>:per_page</tt>:
+The number of rows per page is set with +:per_page+:
 
   @tasks_grid = initialize_grid(Task, per_page: 40)
 
 == 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:
+The +initialize_grid+ method supports a +:conditions+ 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]
@@ -335,9 +337,9 @@ Alternatively, instead of a Class object as the first parameter, you can use  Ac
   )
 
 
-Please note that though all queries inside of WiceGrid are run without the default
-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>:
+Please note that though all queries inside of WiceGrid are run without the default scope, if you use an
+ActiveRecord::Relation instance to initialize grid, it will already include the default scope. Thus you
+might consider using +unscoped+:
 
   @tasks_grid = initialize_grid(
     Task.unscoped.where(archived: false, projects: {active: true}).joins(:project)
@@ -345,7 +347,7 @@ already include the default scope. Thus you might consider using <tt>unscoped</t
 
 == Queries with join tables
 
-WiceGrid also supports ActiveRecord's <tt>:joins</tt> and <tt>:include</tt>.
+WiceGrid also supports ActiveRecord's +:joins+ and +:include+.
 
   @products_grid = initialize_grid(Product,
     include:  :category,
@@ -353,11 +355,11 @@ WiceGrid also supports ActiveRecord's <tt>:joins</tt> and <tt>:include</tt>.
     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>
+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, +products.name+.
 
-To show columns of joined tables in the view table, the ActiveRecord model class name has
-to be specified, that corresponds to the joined table:
+To show columns of joined tables in the view table, the ActiveRecord model class name has 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
@@ -369,15 +371,15 @@ to be specified, that corresponds to the joined table:
     end
   %>
 
-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>
+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
 
-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:
 
@@ -410,11 +412,11 @@ View:
 
 == 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.
 
@@ -424,12 +426,12 @@ The name can only contain alphanumeric characters.
 
 == 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
+<tt>ORDER BY</tt> clause.
 
 For example:
 
@@ -455,8 +457,8 @@ Values can also be Proc objects. The parameter supplied to such a Proc object is
 
 == Filters
 
-Each column filter type is supported by a <tt>column processor</tt>.
-Each <tt>column processor</tt> is responsible for
+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
@@ -491,23 +493,22 @@ Which Column Processor is instantiated for which data types is defined in file
     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.
+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".
+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. A custom dropdown filter
-is essentially a dropdown list.
+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:
+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
@@ -515,8 +516,8 @@ Depending on the value of
 An array of two-element arrays or a hash are semantically identical ways of creating a custom filter.
 
 Every first item of the two-element array is used for the label of the select option while the second
-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:
+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'}
@@ -524,27 +525,29 @@ of the generated dropdown list, while the values will be values of options of th
   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:
+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']
 
 
 ==== :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>, if present.
+<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>, if present.
 
   g.column name: 'Status', attribute: 'status', custom_filter: :auto
 
-In the above example all statuses will appear in the dropdown even if they don't appear in the current resultset.
+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)
 
 In most cases custom fields are needed for one-to-many and many-to-many associations.
 
-To correctly build a filter condition foreign keys have to be used, not the actual values rendered in the column.
+To correctly build a filter condition foreign keys have to be used, not the actual values rendered in the
+column.
 
 For example, if there is a column:
 
@@ -559,11 +562,12 @@ adding <tt>:custom_filter</tt> like this:
     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.
+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, 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:
+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',
@@ -571,8 +575,8 @@ To use filter with foreign keys, it is advised to change the declaration of the
     task.project.name if task.project
   end
 
-However, this will break the ordering of the column - the column will be ordered by the integer foreign key.
-To fix this, we can override the ordering using <tt>:custom_order</tt>:
+However, this will break the ordering of the column - the column will be ordered by the integer foreign
+key. To fix this, we can override the ordering using <tt>:custom_order</tt>:
 
   @tasks_grid = initialize_grid(Task,
     include: :project,
@@ -585,16 +589,15 @@ 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.
+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.
 
-For an array of symbols, the first method name is sent to the ActiveRecord
-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.
+For an array of symbols, the first method name is sent to the ActiveRecord 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|
     task.expected_version.name if task.expected_version
@@ -607,18 +610,19 @@ There are two important differences from <tt>:auto</tt>:
 2. Filtering by any option of such a custom filter will bring a non-empty list, unlike with <tt>:auto</tt>.
 
 
-This mode has one major drawback - this mode requires an additional query
-without +offset+ and +limit+ clauses to instantiate _all_
-ActiveRecord objects, and performance-wise it brings all the advantages of pagination to nothing.
-Thus, memory- and performance-wise this can be really bad for some queries and tables and should be used with care.
+This mode has one major drawback - this mode requires an additional query without +offset+ and +limit+
+clauses to instantiate _all_ ActiveRecord objects, and performance-wise it brings all the advantages of
+pagination to nothing. Thus, memory- and performance-wise this can be really bad for some queries and
+tables and should be used with care.
 
 
-If the final method returns a atomic value like a string or an integer,
-it is used for both the value and the label of the select option element:
+If the final method returns a atomic value like a string or an integer, it is used for both the value and
+the label of the select option element:
 
   <option value="returned value">returned value</option>
 
-However, if the retuned value is a two element array, the first element is used for the option label and the second - for the value.
+However, if the retuned value is a two element array, the first element is used for the option label and
+the second - for the value.
 
 Typically, a model method like the following:
 
@@ -634,8 +638,8 @@ would do the trick:
 
   <option value="id">name</option>
 
-Alternatively, a hash with the single key-value pair can be used, where the key will be used for the label,
-and the key - for the value:
+Alternatively, a hash with the single key-value pair can be used, where the key will be used for the
+label, and the key - for the value:
 
   def to_option
     {name => id}
@@ -644,11 +648,14 @@ 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.
-Value 'null' is transformed into SQL condition <tt>IS NULL</tt>, and 'not null' into <tt>IS NOT NULL</tt>
+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 +IS NULL+, and +not null+ into
+<tt>IS NOT NULL</tt>.
 
 Thus, if in a filter defined by
-     :custom_filter => {'No' => 'null', 'Yes' => 'not null', '1' => 1, '2' => '2', '3' => '3'}
+
+     custom_filter: {'No' => 'null', 'Yes' => 'not null', '1' => 1, '2' => '2', '3' => '3'}
+
 values '1', '2' and 'No' are selected (in a multi-select mode),  this will result in the following SQL:
 
     ( table.field IN ( '1', '2' ) OR table.field IS NULL )
@@ -668,9 +675,9 @@ To only allow single selection use <tt>:allow_multiple_selection</tt>:
 
 === 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>:
+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|
     ...
@@ -679,18 +686,21 @@ with value <tt>:range</tt>:
 
 === Date and DateTime Filters
 
-WiceGrid provides three ways of selecting dates and times. The default style is
-set in <tt>config/initializers/wice_grid_config.rb</tt> using the HELPER_STYLE
-constant. The available options are <tt>:calendar</tt> (jQueryUI datepicker),
-<tt>:html5</tt> and <tt>:standard</tt>. The style can also be individually
-configured via the <tt>helper_style</tt> option on a Date/DateTime filter
-column configuration:
+WiceGrid provides four ways of selecting dates and times. The default style is set in
+<tt>config/initializers/wice_grid_config.rb</tt> using the HELPER_STYLE constant. The available options are
+
+* <tt>:calendar</tt> (jQuery UI datepicker),
+* <tt>:bootstrap</tt> {Bootstrap datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails],
+* <tt>:standard</tt>.
+
+The style can also be individually configured via the <tt>helper_style</tt> option on a Date/DateTime
+filter column configuration:
 
   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: 'Created', attribute: 'created_at', helper_style: :html5 do |task|
+  g.column name: 'Created', attribute: 'created_at', helper_style: :bootstrap do |task|
     task.created_at.to_s(:short)
   end
 
@@ -698,18 +708,22 @@ column configuration:
     task.created_at.to_s(:short)
   end
 
-==== jQueryUI DatePicker
 
-By default WiceGrid uses jQueryUI datepicker[http://jqueryui.com/demos/datepicker/] for Date and DateTime filters.
-Because this is part of the standard jQueryUI codebase, it is not bundled together with the plugin,
-and it is the responsibility of the programmer to include all necessary assets including
+
+==== jQuery UI DatePicker <tt>(HELPER_STYLE = :calendar)</tt>
+
+By default WiceGrid uses jQuery UI datepicker[http://jqueryui.com/demos/datepicker/] for Date and DateTime
+filters. Because this is part of the standard jQuery UI 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.
 
-jQueryUI datepicker does not have any time related controls, and when dealing with DateTime filters, the time value is ignored.
+jQuery UI datepicker does not have any time related controls, and when dealing with DateTime filters, the
+time value is ignored.
 
-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.
+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
@@ -721,24 +735,15 @@ you can always change this range dynamically with the following javascript:
 
   $( ".hasDatepicker" ).datepicker( "option", "yearRange", "2000:2042" );
 
-==== HTML5 input[type=date] DatePicker
 
-In stead of the jQueryUI version of the datepicker some Browsers implement
-their own datepicker which can be used as well without having to rely on
-jQueryUI.
+==== jQuery UI DatePicker <tt>(HELPER_STYLE = :bootstrap)</tt>
 
-This helper_style actually also lets you use other javascript datepickers as
-well. For example if you want to use the
-bootstrap-datetimepicker[https://github.com/Eonasdan/bootstrap-datetimepicker]
-with a timepicker, you would do this:
+WiceGrid also supports {Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails].
 
-  $('input[type=date]').attr("type","text").datetimepicker();
+==== Rails standard input fields <tt>(HELPER_STYLE = :standard)</tt>
 
-==== Rails standard input fields
-
-Another option is standard Rails helpers for date fields, these are separate
-select fields for years, months and days (also for hour and minute if it is a
-datetime field).
+Another option is standard Rails helpers for date fields, these are separate select fields for years,
+months and days (also for hour and minute if it is a datetime field).
 
 == Detached Filters
 
@@ -746,10 +751,10 @@ 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.
+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|
 
@@ -783,24 +788,23 @@ Then, use <tt>grid_filter(grid, :some_filter_name)</tt> to render filters:
   <%= grid(@tasks_grid) %>
 
 
-Finally, use <tt>render_grid(@grid)</tt> to actually output the grid table .
+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').
+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.
+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.
+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>:
@@ -827,8 +831,8 @@ The structure of these two classes is as follows:
 
     def yield_declaration_of_column_filter
       {
-        :templates => [...],
-        :ids       => [...]
+        templates:  [...],
+        ids:        [...]
       }
     end
   end
@@ -861,8 +865,8 @@ whose value is the name of the grid:
       <button class="wg-external-submit-button" data-grid-name="grid">Submit</button>
       <button class="wg-external-reset-button" data-grid-name="grid">Reset</button>
 
-To hide the default icons use <tt>:hide_submit_button => true</tt> and
-<tt>:hide_reset_button => true</tt> in the +grid+ helper.
+To hide the default icons use <tt>hide_submit_button: true</tt> and
+<tt>hide_reset_button: true</tt> in the +grid+ helper.
 
 
 
@@ -920,7 +924,7 @@ string output whole the second is a hash of HTML attributes to be added for the
 
   g.column  do |portal_application|
     css_class = portal_application.public? ? 'public' : 'private'
-    [portal_application.name, {:class => css_class}]
+    [portal_application.name, {class: css_class}]
   end
 
 For adding classes/styles to <tt><TR></tt> use special clause  +row_attributes+ ,
@@ -929,7 +933,7 @@ similar to +column+, only returning a hash:
     <%= grid(@versions_grid) do |g|
       g.row_attributes do |version|
         if version.in_production?
-          {:style => 'background-color: rgb(255, 255, 204);'}
+          {style: 'background-color: rgb(255, 255, 204);'}
         end
       end
 
@@ -961,8 +965,8 @@ This works similar to +row_attributes+, by adding blocks +after_row+, +before_ro
       content_tag(:tr,
         content_tag(:td,
           'Last row',
-        :colspan => 10),
-       :class => 'last_row')
+        colspan: 10),
+       class: 'last_row')
     end
 
     .......
@@ -998,7 +1002,7 @@ There are two alternative ways to do the same, submitting a string to +blank_sla
 
 Or a partial:
 
-  g.blank_slate :partial => "partial_name"
+  g.blank_slate partial: "partial_name"
 
 
 == Action Column
@@ -1008,7 +1012,7 @@ for example, deleting selected records. Please note that +action_column+ only cr
 'Select All' and 'Deselect All' buttons, and the form itself as well as processing the parameters should be
 taken care of by the application code.
 
-  <%= grid(@tasks_grid, :show_filters => :always) do |g|
+  <%= grid(@tasks_grid, show_filters: :always) do |g|
 
     ...
 
@@ -1025,7 +1029,7 @@ By default the name of the HTTP parameter follows pattern <tt>"#{grid_name}[#{pa
 You can hide a certain action checkbox if you add the usual block to +g.action_column+, just like with the
 +g.column+ definition. If the block returns +nil+ or +false+ no checkbox will be rendered.
 
-  <%= grid(@tasks_grid, :show_filters => :always) do |g|
+  <%= grid(@tasks_grid, show_filters: :always) do |g|
 
     ...
 
@@ -1054,11 +1058,11 @@ WiceGrid allows to keep the status of the grid with all the filtering and sortin
 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 %>
+  <% form_tag('', method: :get) do %>
     <%= dump_filter_parameters_as_hidden_fields(@tasks_grid) %>
     <%= select_tag 'archived',
        options_for_select([['View active tasks', 0], ['View archived tasks', 1]], @archived ? 1 : 0),
-      :onchange => 'this.form.submit()' %>
+      onchange: 'this.form.submit()' %>
   <% end -%>
 
 
@@ -1067,7 +1071,7 @@ all current sorting and filtering parameters as hidden fields. Just include
 
 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,
-change constant +ALLOW_SHOWING_ALL_QUERIES+ in <tt>config/initializers/wice_grid_config.rb</tt> to
+change constant +ALLOW_SHOWING_ALL_RECORDS+ in <tt>config/initializers/wice_grid_config.rb</tt> to
 +false+. To do so for a specific grid, use initializer parameter <tt>:allow_showing_all_records</tt>.
 
 Configuration constant +START_SHOWING_WARNING_FROM+ sets the threshold number of all records after
@@ -1311,6 +1315,11 @@ only under certain circumstances:
 
 == Icons
 
-Icons used by the plugin are courtesy of Mark James, the creator of the SILK icon set -
-http://www.famfamfam.com/lab/icons/silk/.
+Icons used by the plugin are courtesy of Mark James, the creator of {the SILK icon set}[http://www.famfamfam.com/lab/icons/silk/].
+
+== Bug reports
+
+The author of the plugins welcomes any contribution.
+Please follow {these guidelines}[https://github.com/leikind/wice_grid/wiki/How-to-submit-a-bug-report-or-a-question] when submitting a bug report.
+