wice_grid 3.4.14 → 3.5.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.gitignore +1 -0
- data/CHANGELOG +38 -0
- data/README.rdoc +219 -210
- data/SAVED_QUERIES_HOWTO.rdoc +13 -13
- data/app/views/kaminari/wice_grid/_next_page.html.erb +1 -1
- data/app/views/kaminari/wice_grid/_page.html.erb +1 -1
- data/app/views/kaminari/wice_grid/_prev_page.html.erb +1 -1
- data/lib/generators/wice_grid/install_generator.rb +2 -2
- data/lib/generators/wice_grid/templates/{wice_grid.css.scss → wice_grid.scss} +0 -0
- data/lib/generators/wice_grid/templates/wice_grid.yml +87 -1
- data/lib/generators/wice_grid/templates/wice_grid_config.rb +21 -7
- data/lib/wice/active_record_column_wrapper.rb +0 -1
- data/lib/wice/columns.rb +0 -1
- data/lib/wice/columns/column_action.rb +13 -8
- data/lib/wice/columns/column_boolean.rb +0 -1
- data/lib/wice/columns/column_custom_dropdown.rb +0 -1
- data/lib/wice/columns/column_date.rb +1 -2
- data/lib/wice/columns/column_datetime.rb +33 -7
- data/lib/wice/columns/column_float.rb +0 -1
- data/lib/wice/columns/column_integer.rb +0 -1
- data/lib/wice/columns/column_processor_index.rb +0 -1
- data/lib/wice/columns/column_range.rb +0 -1
- data/lib/wice/columns/column_string.rb +0 -1
- data/lib/wice/grid_output_buffer.rb +0 -1
- data/lib/wice/grid_renderer.rb +4 -2
- data/lib/wice/helpers/bs_calendar_helpers.rb +67 -0
- data/lib/wice/helpers/wice_grid_misc_view_helpers.rb +0 -1
- data/lib/wice/helpers/wice_grid_serialized_queries_view_helpers.rb +16 -17
- data/lib/wice/helpers/wice_grid_view_helpers.rb +52 -54
- data/lib/wice/kaminari_monkey_patching.rb +0 -1
- data/lib/wice/table_column_matrix.rb +0 -1
- data/lib/wice/wice_grid_controller.rb +5 -7
- data/lib/wice/wice_grid_core_ext.rb +0 -2
- data/lib/wice/wice_grid_misc.rb +0 -1
- data/lib/wice/wice_grid_serialized_queries_controller.rb +0 -1
- data/lib/wice/wice_grid_serialized_query.rb +0 -1
- data/lib/wice/wice_grid_spreadsheet.rb +0 -1
- data/lib/wice_grid.rb +24 -14
- data/release_notes/RELEASE_NOTES_3.2.pre1.rdoc +1 -2
- data/vendor/assets/javascripts/wice_grid_init.js.coffee +58 -24
- data/vendor/assets/javascripts/wice_grid_processor.js.coffee +1 -1
- data/wice_grid.gemspec +16 -30
- metadata +22 -21
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: adffa454db1aaf48823d131bb5069b8ca23dcbad
|
4
|
+
data.tar.gz: 75d831e4513a585cfcf1900bf3b84fb68d445c9e
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 22ba98f7d7dc809b16ecb599b14ba96a09a3e6d55eb4d70ef6b14a68a1cc86f0e0cb11712facf429c6a5b562536ead818c5fd06fb38566ffdaf33a091ed24fe9
|
7
|
+
data.tar.gz: bcb4e05fa26aa09d0f4576ca4240b9646cdf354b702267645d815cf02eb634fb127c7bbd417872c2aea8742a2f5a060ecef6b6625d58ef05d036f25d84853531
|
data/.gitignore
CHANGED
data/CHANGELOG
CHANGED
@@ -1,3 +1,41 @@
|
|
1
|
+
3.5.0
|
2
|
+
|
3
|
+
New features:
|
4
|
+
|
5
|
+
* In addition to two icons "SET ALL" and "UNSET ALL" in the action column, there is now
|
6
|
+
an option to use a standard HTML checkbox. This is now the default.
|
7
|
+
* Support for Bootstrap Datepicker. A suggested way to use Bootstrap Datepicker in a Rails app
|
8
|
+
is https://github.com/Nerian/bootstrap-datepicker-rails. Configuration variable HELPER_STYLE
|
9
|
+
sets the default flavor of date pickers.
|
10
|
+
|
11
|
+
* :calendar jQuery UI datepicker
|
12
|
+
* :bootstrap Bootstrap datepicker
|
13
|
+
* :standard
|
14
|
+
* Italian locale
|
15
|
+
* Spanish locale
|
16
|
+
* various fixes
|
17
|
+
* Configuration variable ALLOW_SHOWING_ALL_QUERIES renamed to ALLOW_SHOWING_ALL_RECORDS
|
18
|
+
|
19
|
+
Can also be set per grid with helper_style: :bootstrap
|
20
|
+
|
21
|
+
3.4.14
|
22
|
+
|
23
|
+
Wice::Defaults::HIDE_ALL_LINK_FROM is nil by default
|
24
|
+
|
25
|
+
3.4.13
|
26
|
+
|
27
|
+
New configuration variable Wice::Defaults::HIDE_ALL_LINK_FROM! When set and the total
|
28
|
+
number of row exceeds its value, the "SHOW ALL" link disappears.
|
29
|
+
|
30
|
+
3.4.12
|
31
|
+
|
32
|
+
fixes
|
33
|
+
|
34
|
+
3.4.11
|
35
|
+
|
36
|
+
started adding HTML5 datepicker
|
37
|
+
changed how relations are detected so that it can work with relation proxies (aka octopus)
|
38
|
+
|
1
39
|
3.4.10
|
2
40
|
|
3
41
|
bug fixes
|
data/README.rdoc
CHANGED
@@ -1,100 +1,98 @@
|
|
1
1
|
= WiceGrid
|
2
2
|
|
3
|
-
Version:: 3.
|
3
|
+
Version:: 3.5.0
|
4
4
|
Author:: Yuri Leikind
|
5
5
|
Sources:: https://github.com/leikind/wice_grid/
|
6
6
|
Examples online:: http://wicegrid.herokuapp.com
|
7
|
-
News:: http://leikind.org/tag/wicegrid/
|
8
7
|
Email:: "Yuri Leikind" <yuri.leikind at gmail dot com>
|
9
8
|
|
10
9
|
|
11
|
-
The main supported branch is +rails3+. Rails 3 and Rails 4 are supported.
|
12
|
-
|
13
|
-
For rails 2 use the +master+ branch: https://github.com/leikind/wice_grid/tree/master
|
14
|
-
|
15
10
|
|
16
11
|
== Intro
|
17
12
|
|
18
13
|
WiceGrid is a Rails grid plugin.
|
19
14
|
|
20
|
-
One of the goals of this plugin was to allow the programmer to define the contents of the cell
|
21
|
-
just like one does when rendering a collection via a simple table (and this is what differentiates
|
22
|
-
from various scaffolding solutions), but automate implementation of filters, ordering,
|
23
|
-
CSV export, and so on. Ruby blocks provide an elegant means for this.
|
15
|
+
One of the goals of this plugin was to allow the programmer to define the contents of the cell on their
|
16
|
+
own, just like one does when rendering a collection via a simple table (and this is what differentiates
|
17
|
+
WiceGrid from various scaffolding solutions), but automate implementation of filters, ordering,
|
18
|
+
paginations, CSV export, and so on. Ruby blocks provide an elegant means for this.
|
24
19
|
|
25
20
|
|
26
21
|
WiceGrid builds the call to the ActiveRecord layer for you and creates a table view with the results
|
27
22
|
of the call including:
|
28
23
|
|
29
|
-
*
|
24
|
+
* pagination
|
30
25
|
* sortable columns
|
31
26
|
* filtering by multiple columns
|
32
27
|
* CSV export
|
33
|
-
*
|
28
|
+
* saved queries
|
34
29
|
|
35
|
-
|
36
|
-
|
37
|
-
|
30
|
+
Filters are added automatically according to the type of the underlying DB column. Filtering by more
|
31
|
+
than one column at the same time is possible. More than one such grid can appear on a page, and
|
32
|
+
manipulations with one grid do not have any impact on others.
|
38
33
|
|
39
34
|
WiceGrid does not take a collection as an input, it works directly with ActiveRecord.
|
40
35
|
|
41
|
-
WiceGrid does not use
|
42
|
-
nevertheless, all other page parameters are respected and preserved.
|
36
|
+
WiceGrid does not use XHR calls to reload itself, instead simple GET requests are used for this,
|
37
|
+
nevertheless, all other page parameters are respected and preserved. WiceGrid works well with Turbolinks.
|
38
|
+
|
43
39
|
WiceGrid views do not contain forms so you can include it in your own forms.
|
44
40
|
|
45
41
|
WiceGrid is known to work with MySQL and Postgres.
|
46
42
|
|
43
|
+
|
44
|
+
|
47
45
|
=== Examples
|
48
46
|
|
49
|
-
This tutorial is accompanied by a sample application with WiceGrid examples which you
|
50
|
-
|
51
|
-
or just view the code: https://github.com/leikind/wice_grid_testbed.
|
47
|
+
This tutorial is accompanied by a sample application with WiceGrid examples which you can browse online:
|
48
|
+
http://wicegrid.herokuapp.com, or just view the code: https://github.com/leikind/wice_grid_testbed.
|
52
49
|
|
53
50
|
|
54
|
-
== Requirements
|
55
51
|
|
56
|
-
|
57
|
-
For Rails 3.0.x and 3.1.x versions use version 3.0.4.
|
58
|
-
For Rails 2 use version 0.6 (https://github.com/leikind/wice_grid/tree/master).
|
52
|
+
== Requirements and Rails versions
|
59
53
|
|
60
|
-
|
61
|
-
|
54
|
+
For rails 2 use version 0.6 in {the master branch}[https://github.com/leikind/wice_grid/tree/master].
|
55
|
+
That branch is hardly supported.
|
62
56
|
|
57
|
+
The main supported branch is +rails3+. Latest Rails 3.2.x and Rails 4.x.x are supported in this branch.
|
63
58
|
|
59
|
+
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.
|
64
60
|
|
61
|
+
WiceGrid relies on jQuery.
|
65
62
|
|
66
|
-
|
63
|
+
If you need a JS Datepicker, WiceGrid supports jQuery Datepicker or
|
64
|
+
{Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails], so you might need one of
|
65
|
+
those. See section Installation for details on how to use datepickers.
|
67
66
|
|
68
|
-
WiceGrid
|
69
|
-
|
70
|
-
Beginning from version 3.2 only jQuery is supported.
|
67
|
+
WARNING: Since 3.2.pre2 WiceGrid is not compatible with +will_paginate+ because internally it uses
|
68
|
+
+kaminari+ for pagination, and +kaminari+ is not compatible with +will_paginate+!
|
71
69
|
|
72
70
|
|
73
71
|
== Installation
|
74
72
|
|
75
73
|
Add the following to your Gemfile:
|
76
74
|
|
77
|
-
gem "wice_grid", '3.
|
75
|
+
gem "wice_grid", '3.5.0'
|
78
76
|
|
79
|
-
and run the
|
77
|
+
and run the +bundle+ command.
|
80
78
|
|
81
79
|
Run the generator:
|
82
80
|
|
83
81
|
rails g wice_grid:install
|
84
82
|
|
85
83
|
This adds the config file <tt>wice_grid_config.rb</tt> to <tt>config/initializers/</tt>, the locale file
|
86
|
-
<tt>wice_grid.yml</tt> to <tt>config/locales/</tt>, and the styles file
|
87
|
-
<tt>
|
84
|
+
<tt>wice_grid.yml</tt> to <tt>config/locales/</tt>, and the styles file <tt>wice_grid.scss</tt> to
|
85
|
+
<tt>app/assets/stylesheets/</tt>.
|
88
86
|
|
89
87
|
Require WiceGrid javascript in your js index file:
|
90
88
|
|
91
89
|
//= require wice_grid
|
92
90
|
|
93
|
-
Make sure
|
94
|
-
|
95
|
-
|
96
|
-
Here is an example of application.js with everything WiceGrid needs:
|
91
|
+
Make sure jQuery is loaded. If the application uses Date and DateTime filters, you have to install
|
92
|
+
jQuery Datepicker by yourself. You can also use
|
93
|
+
{Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails].
|
97
94
|
|
95
|
+
Here is an example of +application.js+ if jquery.ui.datepicker is used:
|
98
96
|
//= require jquery
|
99
97
|
//= require jquery_ujs
|
100
98
|
//= require jquery-ui
|
@@ -102,9 +100,17 @@ Here is an example of application.js with everything WiceGrid needs:
|
|
102
100
|
//= require jquery.ui.datepicker
|
103
101
|
//= require_tree .
|
104
102
|
|
105
|
-
|
106
|
-
|
107
|
-
|
103
|
+
Here is +application.js+ if {Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails] is used:
|
104
|
+
//= require jquery
|
105
|
+
//= require jquery_ujs
|
106
|
+
//= require jquery-ui
|
107
|
+
//= require wice_grid
|
108
|
+
//= require bootstrap-datepicker
|
109
|
+
//= require_tree .
|
110
|
+
|
111
|
+
WiceGrid provides some very basic styles, not specifying exactly how the table should look like, but if
|
112
|
+
the application uses Twitter Bootstrap, the markup generated by WiceGrid will have correct classes and
|
113
|
+
will fit nicely. Generally it is advised to modify WiceGrid css to match the application style.
|
108
114
|
|
109
115
|
|
110
116
|
== Basics
|
@@ -117,7 +123,7 @@ Controller:
|
|
117
123
|
|
118
124
|
It is also possible to use an ActiveRecord::Relation instance as the first argument:
|
119
125
|
|
120
|
-
@tasks_grid = initialize_grid(Task.where(:
|
126
|
+
@tasks_grid = initialize_grid(Task.where(active: true))
|
121
127
|
|
122
128
|
View:
|
123
129
|
|
@@ -146,10 +152,9 @@ View:
|
|
146
152
|
|
147
153
|
Code <tt>g.column do |task| ... end</tt>
|
148
154
|
defines everything related to a column in the resulting view table including column names, sorting,
|
149
|
-
filtering, the content of the column cells, etc.
|
150
|
-
The return value of the block is the table cell content.
|
155
|
+
filtering, the content of the column cells, etc. The return value of the block is the table cell content.
|
151
156
|
|
152
|
-
Column names are defined with parameter
|
157
|
+
Column names are defined with parameter +:name+:
|
153
158
|
|
154
159
|
<%= grid(@tasks_grid) do |g|
|
155
160
|
|
@@ -174,8 +179,8 @@ Column names are defined with parameter <tt>:name</tt>:
|
|
174
179
|
end
|
175
180
|
end -%>
|
176
181
|
|
177
|
-
To add filtering and ordering, declare to which column in the underlying database
|
178
|
-
|
182
|
+
To add filtering and ordering, declare to which column in the underlying database table(s) the view
|
183
|
+
column corresponds using parameter +:attribute+:
|
179
184
|
|
180
185
|
<%= grid(@tasks_grid) do |g|
|
181
186
|
|
@@ -200,31 +205,28 @@ table(s) the view column corresponds using parameter <tt>:attribute</tt> :
|
|
200
205
|
end
|
201
206
|
end -%>
|
202
207
|
|
203
|
-
This will add sorting links and filters for columns +Username+ and +Active+.
|
204
|
-
|
205
|
-
|
206
|
-
|
207
|
-
|
208
|
-
added which can contain the numeric range (more than, less than).
|
208
|
+
This will add sorting links and filters for columns +Username+ and +Active+. The plugin automatically
|
209
|
+
creates filters according to the type of the database column. In the above example a text field will be
|
210
|
+
created for column Title (title is a string), for column +Archived+ a dropdown filter will be created
|
211
|
+
with options 'Yes', 'No', and '--', and for the integer ID two short text fields are added which can
|
212
|
+
contain the numeric range (more than, less than).
|
209
213
|
|
210
|
-
It is important to remember that
|
211
|
-
not
|
212
|
-
|
213
|
-
but not all model attributes map to columns in the same table with the same name.
|
214
|
+
It is important to remember that +:attribute+ is the name of the database column, not a model attribute.
|
215
|
+
Of course, all database columns have corresponding model attributes, but not all model attributes map to
|
216
|
+
columns in the same table with the same name.
|
214
217
|
|
215
|
-
Read more about available filters in the documentation
|
216
|
-
for the column method.
|
218
|
+
Read more about available filters in the documentation for the column method.
|
217
219
|
|
218
220
|
Read the section about custom dropdown filters for more advanced filters.
|
219
221
|
|
220
|
-
|
221
222
|
For columns like
|
222
223
|
|
223
224
|
g.column name: 'Title', attribute: 'title' do |task|
|
224
225
|
task.title
|
225
226
|
end
|
226
227
|
|
227
|
-
where the block contains just a call to the same attribute declared by :attribute, the block can be
|
228
|
+
where the block contains just a call to the same attribute declared by :attribute, the block can be
|
229
|
+
omitted:
|
228
230
|
|
229
231
|
<%= grid(@tasks_grid) do |g|
|
230
232
|
|
@@ -246,7 +248,7 @@ where the block contains just a call to the same attribute declared by :attribut
|
|
246
248
|
|
247
249
|
In this case +name+ will be used as the method name to send to the ActiveRecord instance.
|
248
250
|
|
249
|
-
If only ordering is needed, and no filter, we can turn off filters using
|
251
|
+
If only ordering is needed, and no filter, we can turn off filters using +:filter+ :
|
250
252
|
|
251
253
|
g.column name: 'ID', attribute: 'id', filter: false
|
252
254
|
|
@@ -254,9 +256,9 @@ If no ordering links are needed, use <tt>ordering: false</tt>:
|
|
254
256
|
|
255
257
|
g.column name: 'Added', attribute: 'created_at', ordering: false
|
256
258
|
|
257
|
-
It is important to understand that it is up to the developer to make sure that the value
|
258
|
-
|
259
|
-
|
259
|
+
It is important to understand that it is up to the developer to make sure that the value returned by a
|
260
|
+
column block (the content of a cell) corresponds to the underlying database column specified by
|
261
|
+
+:attribute+ (and +:model+ discussed below).
|
260
262
|
|
261
263
|
|
262
264
|
== Rendering filter panel
|
@@ -264,12 +266,12 @@ column specified by <tt>:attribute</tt> (and <tt>:model</tt> discussed below).
|
|
264
266
|
The filter panel can be shown and hidden clicking the icon with binoculars.
|
265
267
|
|
266
268
|
The way the filter panel is shown after the page is loaded is controlled via parameter
|
267
|
-
|
269
|
+
+:show_filters+ of the +grid+ helper.
|
268
270
|
Possible values are:
|
269
271
|
|
270
|
-
*
|
271
|
-
*
|
272
|
-
*
|
272
|
+
* +:when_filtered+ - the filter is shown when the current table is the result of filtering
|
273
|
+
* +:always+ - always show the filter
|
274
|
+
* +:no+ - never show the filter
|
273
275
|
|
274
276
|
Example:
|
275
277
|
|
@@ -278,17 +280,17 @@ Example:
|
|
278
280
|
end -%>
|
279
281
|
|
280
282
|
|
281
|
-
Filter related icons (filter icon, reset icon, show/hide icon) are placed in the header of the last
|
282
|
-
it doesn't have any filter or a column name, otherwise an additional table column is added.
|
283
|
-
the icons in the additional column, set
|
284
|
-
the configuration file.
|
283
|
+
Filter related icons (filter icon, reset icon, show/hide icon) are placed in the header of the last
|
284
|
+
column if it doesn't have any filter or a column name, otherwise an additional table column is added.
|
285
|
+
To always place the icons in the additional column, set
|
286
|
+
<tt>Wice::Defaults::REUSE_LAST_COLUMN_FOR_FILTER_ICONS</tt> to +false+ in the configuration file.
|
285
287
|
|
286
288
|
|
287
289
|
== Initial Ordering
|
288
290
|
|
289
|
-
Initializing the grid we can also define the column by which the record will be ordered
|
290
|
-
|
291
|
-
|
291
|
+
Initializing the grid we can also define the column by which the record will be ordered <em>on the first
|
292
|
+
rendering of the grid</em>, when the user has not set their ordering setting by clicking the column label,
|
293
|
+
and the order direction:
|
292
294
|
|
293
295
|
@tasks_grid = initialize_grid(Task,
|
294
296
|
order: 'tasks.title',
|
@@ -297,14 +299,14 @@ setting by clicking the column label, and the order direction:
|
|
297
299
|
|
298
300
|
== Records Per Page
|
299
301
|
|
300
|
-
The number of rows per page is set with
|
302
|
+
The number of rows per page is set with +:per_page+:
|
301
303
|
|
302
304
|
@tasks_grid = initialize_grid(Task, per_page: 40)
|
303
305
|
|
304
306
|
== Conditions
|
305
307
|
|
306
|
-
The +initialize_grid+ method supports a
|
307
|
-
|
308
|
+
The +initialize_grid+ method supports a +:conditions+ parameter which is passed on to the underlying
|
309
|
+
ActiveRecord, so it can be in any format processable by ActiveRecord:
|
308
310
|
|
309
311
|
@tasks_grid = initialize_grid(Task,
|
310
312
|
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
|
|
335
337
|
)
|
336
338
|
|
337
339
|
|
338
|
-
Please note that though all queries inside of WiceGrid are run without the default
|
339
|
-
|
340
|
-
|
340
|
+
Please note that though all queries inside of WiceGrid are run without the default scope, if you use an
|
341
|
+
ActiveRecord::Relation instance to initialize grid, it will already include the default scope. Thus you
|
342
|
+
might consider using +unscoped+:
|
341
343
|
|
342
344
|
@tasks_grid = initialize_grid(
|
343
345
|
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
|
|
345
347
|
|
346
348
|
== Queries with join tables
|
347
349
|
|
348
|
-
WiceGrid also supports ActiveRecord's
|
350
|
+
WiceGrid also supports ActiveRecord's +:joins+ and +:include+.
|
349
351
|
|
350
352
|
@products_grid = initialize_grid(Product,
|
351
353
|
include: :category,
|
@@ -353,11 +355,11 @@ WiceGrid also supports ActiveRecord's <tt>:joins</tt> and <tt>:include</tt>.
|
|
353
355
|
per_page: 20
|
354
356
|
)
|
355
357
|
|
356
|
-
Note that if we want to order initially by a column from a joined table we have to specify the
|
357
|
-
|
358
|
+
Note that if we want to order initially by a column from a joined table we have to specify the table and
|
359
|
+
the column name with the sql dot notation, that is, +products.name+.
|
358
360
|
|
359
|
-
To show columns of joined tables in the view table, the ActiveRecord model class name has
|
360
|
-
|
361
|
+
To show columns of joined tables in the view table, the ActiveRecord model class name has to be specified,
|
362
|
+
that corresponds to the joined table:
|
361
363
|
|
362
364
|
<%= grid(@products_grid) do |g|
|
363
365
|
g.column name: 'Product Name', attribute: 'name' do |product| # primary table
|
@@ -369,15 +371,15 @@ to be specified, that corresponds to the joined table:
|
|
369
371
|
end
|
370
372
|
%>
|
371
373
|
|
372
|
-
Please note that the blockless definition of the column only works with columns from the main table
|
373
|
-
|
374
|
+
Please note that the blockless definition of the column only works with columns from the main table and it
|
375
|
+
won't work with columns with <tt>:model</tt>
|
374
376
|
|
375
377
|
== Joined associations referring to the same table
|
376
378
|
|
377
|
-
In case there are two joined associations both referring to the same table, ActiveRecord constructs
|
378
|
-
|
379
|
-
|
380
|
-
|
379
|
+
In case there are two joined associations both referring to the same table, ActiveRecord constructs a query
|
380
|
+
where the second join provides an alias for the joined table. To enable WiceGrid to order and filter by
|
381
|
+
columns belonging to different associations but originating from the same table, set <tt>:table_alias</tt>
|
382
|
+
to this alias:
|
381
383
|
|
382
384
|
Model:
|
383
385
|
|
@@ -410,11 +412,11 @@ View:
|
|
410
412
|
|
411
413
|
== More than one grid on a page
|
412
414
|
|
413
|
-
It is possible to use more that one grid on a page, each with its own state. To do so, you must
|
414
|
-
|
415
|
+
It is possible to use more that one grid on a page, each with its own state. To do so, you must specify the
|
416
|
+
name of the grid in +initialize_grid+ using parameter <tt>:name</tt>.
|
415
417
|
|
416
|
-
The name serves as the base name for HTTP parameters, DOM IDs, etc, so it is important that all
|
417
|
-
|
418
|
+
The name serves as the base name for HTTP parameters, DOM IDs, etc, so it is important that all grids on a
|
419
|
+
page have different names. The default name is 'grid'.
|
418
420
|
|
419
421
|
The name can only contain alphanumeric characters.
|
420
422
|
|
@@ -424,12 +426,12 @@ The name can only contain alphanumeric characters.
|
|
424
426
|
|
425
427
|
== Custom Ordering
|
426
428
|
|
427
|
-
It is possible to change the way results are ordered injecting a chunk of SQL code,
|
428
|
-
|
429
|
+
It is possible to change the way results are ordered injecting a chunk of SQL code, for example, use
|
430
|
+
<tt>ORDER BY INET_ATON(ip_address)</tt> instead of <tt>ORDER BY ip_address</tt>.
|
429
431
|
|
430
|
-
To do so, provide parameter <tt>:custom_order</tt> in the initialization of the grid with
|
431
|
-
|
432
|
-
|
432
|
+
To do so, provide parameter <tt>:custom_order</tt> in the initialization of the grid with a hash where
|
433
|
+
keys are fully qualified names of database columns, and values the required chunks of SQL to use in the
|
434
|
+
<tt>ORDER BY</tt> clause.
|
433
435
|
|
434
436
|
For example:
|
435
437
|
|
@@ -455,8 +457,8 @@ Values can also be Proc objects. The parameter supplied to such a Proc object is
|
|
455
457
|
|
456
458
|
== Filters
|
457
459
|
|
458
|
-
Each column filter type is supported by a <tt>column processor</tt>.
|
459
|
-
|
460
|
+
Each column filter type is supported by a <tt>column processor</tt>. Each <tt>column processor</tt> is
|
461
|
+
responsible for
|
460
462
|
|
461
463
|
* generating HTML and supporting Javascript for the filter, input fields, dropdowns, javascript calendars, etc
|
462
464
|
* 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
|
|
491
493
|
end
|
492
494
|
end
|
493
495
|
|
494
|
-
A good example for using <tt>:filter_type</tt> to change th default is numeric columns.
|
495
|
-
|
496
|
-
|
497
|
-
|
498
|
-
the
|
496
|
+
A good example for using <tt>:filter_type</tt> to change th default is numeric columns. By default
|
497
|
+
<tt>'column_integer'</tt> is instantiated for <tt>integer</tt> columns, and it renders one input field.
|
498
|
+
But it is also possible to use another Column Processor called <tt>'column_range'</tt> which renders two
|
499
|
+
input fields and searches for values in the given the range instead of searching for values which equal
|
500
|
+
the given search term.
|
499
501
|
|
500
|
-
It also possible to define and use your own column processors outside of the plugin, in
|
501
|
-
|
502
|
+
It also possible to define and use your own column processors outside of the plugin, in you application.
|
503
|
+
Read more about this in section "Defining your own external filter processors".
|
502
504
|
|
503
505
|
|
504
506
|
=== Custom dropdown filters
|
505
507
|
|
506
|
-
It is possible to construct custom dropdown filters. A custom dropdown filter
|
507
|
-
|
508
|
+
It is possible to construct custom dropdown filters. A custom dropdown filter is essentially a dropdown
|
509
|
+
list.
|
508
510
|
|
509
|
-
Depending on the value of
|
510
|
-
<tt>column</tt> parameter<tt>:custom_filter</tt> different modes are available:
|
511
|
+
Depending on the value of <tt>column</tt> parameter<tt>:custom_filter</tt> different modes are available:
|
511
512
|
|
512
513
|
|
513
514
|
==== Array of two-element arrays or a hash
|
@@ -515,8 +516,8 @@ Depending on the value of
|
|
515
516
|
An array of two-element arrays or a hash are semantically identical ways of creating a custom filter.
|
516
517
|
|
517
518
|
Every first item of the two-element array is used for the label of the select option while the second
|
518
|
-
element is the value of the select option. In case of a hash the keys become the labels
|
519
|
-
|
519
|
+
element is the value of the select option. In case of a hash the keys become the labels of the generated
|
520
|
+
dropdown list, while the values will be values of options of the dropdown list:
|
520
521
|
|
521
522
|
g.column name: 'Status', attribute: 'status',
|
522
523
|
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
|
|
524
525
|
g.column name: 'Status', attribute: 'status',
|
525
526
|
custom_filter: [['Development', 'development'], ['Testing', 'testing'], ['Production', 'production']]
|
526
527
|
|
527
|
-
It is also possible to submit a array of strings or numbers, in this case every item will be used
|
528
|
-
|
528
|
+
It is also possible to submit a array of strings or numbers, in this case every item will be used both as
|
529
|
+
the value of the select option and as its label:
|
529
530
|
|
530
531
|
g.column name: 'Status', attribute: 'status', custom_filter: ['development', 'testing', 'production']
|
531
532
|
|
532
533
|
|
533
534
|
==== :auto
|
534
535
|
|
535
|
-
<tt>:auto</tt> - a powerful option which populates the dropdown list with all unique values of
|
536
|
-
|
536
|
+
<tt>:auto</tt> - a powerful option which populates the dropdown list with all unique values of the column
|
537
|
+
specified by <tt>:attribute</tt> and <tt>:model</tt>, if present.
|
537
538
|
|
538
539
|
g.column name: 'Status', attribute: 'status', custom_filter: :auto
|
539
540
|
|
540
|
-
In the above example all statuses will appear in the dropdown even if they don't appear in the current
|
541
|
+
In the above example all statuses will appear in the dropdown even if they don't appear in the current
|
542
|
+
resultset.
|
541
543
|
|
542
544
|
|
543
545
|
==== Custom filters and associations (joined tables)
|
544
546
|
|
545
547
|
In most cases custom fields are needed for one-to-many and many-to-many associations.
|
546
548
|
|
547
|
-
To correctly build a filter condition foreign keys have to be used, not the actual values rendered in the
|
549
|
+
To correctly build a filter condition foreign keys have to be used, not the actual values rendered in the
|
550
|
+
column.
|
548
551
|
|
549
552
|
For example, if there is a column:
|
550
553
|
|
@@ -559,11 +562,12 @@ adding <tt>:custom_filter</tt> like this:
|
|
559
562
|
task.project.name if task.project
|
560
563
|
end
|
561
564
|
|
562
|
-
is bad style and can fail, because the resulting condition will compare the name of the project,
|
563
|
-
and in some databases it is possible that different
|
565
|
+
is bad style and can fail, because the resulting condition will compare the name of the project,
|
566
|
+
<tt>projects.name</tt> to a string, and in some databases it is possible that different records
|
567
|
+
(projects in our example) have the same name.
|
564
568
|
|
565
|
-
To use filter with foreign keys, it is advised to change the declaration of the column from
|
566
|
-
<tt>tasks.project_id</tt>, and build the dropdown with foreign keys as values:
|
569
|
+
To use filter with foreign keys, it is advised to change the declaration of the column from
|
570
|
+
<tt>projects.name</tt>, to <tt>tasks.project_id</tt>, and build the dropdown with foreign keys as values:
|
567
571
|
|
568
572
|
|
569
573
|
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
|
|
571
575
|
task.project.name if task.project
|
572
576
|
end
|
573
577
|
|
574
|
-
However, this will break the ordering of the column - the column will be ordered by the integer foreign
|
575
|
-
To fix this, we can override the ordering using <tt>:custom_order</tt>:
|
578
|
+
However, this will break the ordering of the column - the column will be ordered by the integer foreign
|
579
|
+
key. To fix this, we can override the ordering using <tt>:custom_order</tt>:
|
576
580
|
|
577
581
|
@tasks_grid = initialize_grid(Task,
|
578
582
|
include: :project,
|
@@ -585,16 +589,15 @@ To fix this, we can override the ordering using <tt>:custom_order</tt>:
|
|
585
589
|
==== Any other symbol (method name) or an array of symbols (method names)
|
586
590
|
|
587
591
|
|
588
|
-
For one symbol (different from <tt>:auto</tt>) the dropdown list is populated by all unique values
|
589
|
-
|
592
|
+
For one symbol (different from <tt>:auto</tt>) the dropdown list is populated by all unique values returned
|
593
|
+
by the method with this name sent to <em>all</em> ActiveRecord objects throughout all pages.
|
590
594
|
|
591
|
-
The conditions set up by the user are ignored, that is, the records used are all those found on
|
592
|
-
|
595
|
+
The conditions set up by the user are ignored, that is, the records used are all those found on all pages
|
596
|
+
without any filters active.
|
593
597
|
|
594
|
-
For an array of symbols, the first method name is sent to the ActiveRecord
|
595
|
-
|
596
|
-
|
597
|
-
same as an array of symbols where the array contains just one element.
|
598
|
+
For an array of symbols, the first method name is sent to the ActiveRecord object if it responds to this
|
599
|
+
method, the second method name is sent to the returned value unless it is +nil+, and so on. In other
|
600
|
+
words, a single symbol mode is the same as an array of symbols where the array contains just one element.
|
598
601
|
|
599
602
|
g.column name: 'Version', attribute: 'expected_version_id', custom_filter: [:expected_version, :to_option] do |task|
|
600
603
|
task.expected_version.name if task.expected_version
|
@@ -607,18 +610,19 @@ There are two important differences from <tt>:auto</tt>:
|
|
607
610
|
2. Filtering by any option of such a custom filter will bring a non-empty list, unlike with <tt>:auto</tt>.
|
608
611
|
|
609
612
|
|
610
|
-
This mode has one major drawback - this mode requires an additional query
|
611
|
-
|
612
|
-
|
613
|
-
|
613
|
+
This mode has one major drawback - this mode requires an additional query without +offset+ and +limit+
|
614
|
+
clauses to instantiate _all_ ActiveRecord objects, and performance-wise it brings all the advantages of
|
615
|
+
pagination to nothing. Thus, memory- and performance-wise this can be really bad for some queries and
|
616
|
+
tables and should be used with care.
|
614
617
|
|
615
618
|
|
616
|
-
If the final method returns a atomic value like a string or an integer,
|
617
|
-
|
619
|
+
If the final method returns a atomic value like a string or an integer, it is used for both the value and
|
620
|
+
the label of the select option element:
|
618
621
|
|
619
622
|
<option value="returned value">returned value</option>
|
620
623
|
|
621
|
-
However, if the retuned value is a two element array, the first element is used for the option label and
|
624
|
+
However, if the retuned value is a two element array, the first element is used for the option label and
|
625
|
+
the second - for the value.
|
622
626
|
|
623
627
|
Typically, a model method like the following:
|
624
628
|
|
@@ -634,8 +638,8 @@ would do the trick:
|
|
634
638
|
|
635
639
|
<option value="id">name</option>
|
636
640
|
|
637
|
-
Alternatively, a hash with the single key-value pair can be used, where the key will be used for the
|
638
|
-
and the key - for the value:
|
641
|
+
Alternatively, a hash with the single key-value pair can be used, where the key will be used for the
|
642
|
+
label, and the key - for the value:
|
639
643
|
|
640
644
|
def to_option
|
641
645
|
{name => id}
|
@@ -644,11 +648,14 @@ and the key - for the value:
|
|
644
648
|
|
645
649
|
==== Special treatment of values 'null' and 'not null'
|
646
650
|
|
647
|
-
Values
|
648
|
-
Value
|
651
|
+
Values +null+ and +not null+ in a generated custom filter are treated specially, as SQL +null+ statement
|
652
|
+
and not as strings. Value +null+ is transformed into SQL condition +IS NULL+, and +not null+ into
|
653
|
+
<tt>IS NOT NULL</tt>.
|
649
654
|
|
650
655
|
Thus, if in a filter defined by
|
651
|
-
|
656
|
+
|
657
|
+
custom_filter: {'No' => 'null', 'Yes' => 'not null', '1' => 1, '2' => '2', '3' => '3'}
|
658
|
+
|
652
659
|
values '1', '2' and 'No' are selected (in a multi-select mode), this will result in the following SQL:
|
653
660
|
|
654
661
|
( 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>:
|
|
668
675
|
|
669
676
|
=== Numeric Filters
|
670
677
|
|
671
|
-
Before version 3.2.1 the filter used for numeric columns was a range filter with two limits. Beginning
|
672
|
-
the default is a direct comparison filter with one input field. The old range filter
|
673
|
-
with value <tt>:range</tt>:
|
678
|
+
Before version 3.2.1 the filter used for numeric columns was a range filter with two limits. Beginning
|
679
|
+
with version 3.2.1 the default is a direct comparison filter with one input field. The old range filter
|
680
|
+
can still be loaded using parameter <tt>:filter_type</tt> with value <tt>:range</tt>:
|
674
681
|
|
675
682
|
g.column filter_type: :range do |task|
|
676
683
|
...
|
@@ -679,18 +686,21 @@ with value <tt>:range</tt>:
|
|
679
686
|
|
680
687
|
=== Date and DateTime Filters
|
681
688
|
|
682
|
-
WiceGrid provides
|
683
|
-
|
684
|
-
|
685
|
-
<tt>:
|
686
|
-
|
687
|
-
|
689
|
+
WiceGrid provides four ways of selecting dates and times. The default style is set in
|
690
|
+
<tt>config/initializers/wice_grid_config.rb</tt> using the HELPER_STYLE constant. The available options are
|
691
|
+
|
692
|
+
* <tt>:calendar</tt> (jQuery UI datepicker),
|
693
|
+
* <tt>:bootstrap</tt> {Bootstrap datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails],
|
694
|
+
* <tt>:standard</tt>.
|
695
|
+
|
696
|
+
The style can also be individually configured via the <tt>helper_style</tt> option on a Date/DateTime
|
697
|
+
filter column configuration:
|
688
698
|
|
689
699
|
g.column name: 'Due Date', attribute: 'due_date', helper_style: :calendar do |task|
|
690
700
|
task.due_date.to_s(:short) if task.due_date
|
691
701
|
end
|
692
702
|
|
693
|
-
g.column name: 'Created', attribute: 'created_at', helper_style: :
|
703
|
+
g.column name: 'Created', attribute: 'created_at', helper_style: :bootstrap do |task|
|
694
704
|
task.created_at.to_s(:short)
|
695
705
|
end
|
696
706
|
|
@@ -698,18 +708,22 @@ column configuration:
|
|
698
708
|
task.created_at.to_s(:short)
|
699
709
|
end
|
700
710
|
|
701
|
-
==== jQueryUI DatePicker
|
702
711
|
|
703
|
-
|
704
|
-
|
705
|
-
|
712
|
+
|
713
|
+
==== jQuery UI DatePicker <tt>(HELPER_STYLE = :calendar)</tt>
|
714
|
+
|
715
|
+
By default WiceGrid uses jQuery UI datepicker[http://jqueryui.com/demos/datepicker/] for Date and DateTime
|
716
|
+
filters. Because this is part of the standard jQuery UI codebase, it is not bundled together with the
|
717
|
+
plugin, and it is the responsibility of the programmer to include all necessary assets including
|
706
718
|
localization files if the application is multilingual.
|
707
719
|
|
708
|
-
|
720
|
+
jQuery UI datepicker does not have any time related controls, and when dealing with DateTime filters, the
|
721
|
+
time value is ignored.
|
709
722
|
|
710
|
-
Constants +DATE_FORMAT+ and +DATETIME_FORMAT+ in the configuration file define the format of dates the
|
711
|
-
format of the string sent in a HTTP parameter. If you change the formats,
|
712
|
-
in +DATETIME_PARSER+ and +DATE_PARSER+ return valid DateTime and Date
|
723
|
+
Constants +DATE_FORMAT+ and +DATETIME_FORMAT+ in the configuration file define the format of dates the
|
724
|
+
user will see, as well as the format of the string sent in a HTTP parameter. If you change the formats,
|
725
|
+
make sure that lamdbas defined in +DATETIME_PARSER+ and +DATE_PARSER+ return valid DateTime and Date
|
726
|
+
objects.
|
713
727
|
|
714
728
|
jQuery +datepicker+ uses a different format flavor, therefore there is an additional constant
|
715
729
|
+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:
|
|
721
735
|
|
722
736
|
$( ".hasDatepicker" ).datepicker( "option", "yearRange", "2000:2042" );
|
723
737
|
|
724
|
-
==== HTML5 input[type=date] DatePicker
|
725
738
|
|
726
|
-
|
727
|
-
their own datepicker which can be used as well without having to rely on
|
728
|
-
jQueryUI.
|
739
|
+
==== jQuery UI DatePicker <tt>(HELPER_STYLE = :bootstrap)</tt>
|
729
740
|
|
730
|
-
|
731
|
-
well. For example if you want to use the
|
732
|
-
bootstrap-datetimepicker[https://github.com/Eonasdan/bootstrap-datetimepicker]
|
733
|
-
with a timepicker, you would do this:
|
741
|
+
WiceGrid also supports {Bootstrap Datepicker}[https://github.com/Nerian/bootstrap-datepicker-rails].
|
734
742
|
|
735
|
-
|
743
|
+
==== Rails standard input fields <tt>(HELPER_STYLE = :standard)</tt>
|
736
744
|
|
737
|
-
|
738
|
-
|
739
|
-
Another option is standard Rails helpers for date fields, these are separate
|
740
|
-
select fields for years, months and days (also for hour and minute if it is a
|
741
|
-
datetime field).
|
745
|
+
Another option is standard Rails helpers for date fields, these are separate select fields for years,
|
746
|
+
months and days (also for hour and minute if it is a datetime field).
|
742
747
|
|
743
748
|
== Detached Filters
|
744
749
|
|
@@ -746,10 +751,10 @@ Filters can also be detached from the grid table and placed anywhere on page.
|
|
746
751
|
|
747
752
|
This is a 3-step process.
|
748
753
|
|
749
|
-
First, define the grid with helper +define_grid+ instead of +grid+.
|
750
|
-
|
751
|
-
|
752
|
-
or a symbol value which will be used later to identify the filter.
|
754
|
+
First, define the grid with helper +define_grid+ instead of +grid+. Everything should be done the same way
|
755
|
+
as with +grid+, but every column which will have an external filter, add
|
756
|
+
<tt>detach_with_id: :some_filter_name+</tt> in the column definition. The value of +:detach_with_id+ is an
|
757
|
+
arbitrary string or a symbol value which will be used later to identify the filter.
|
753
758
|
|
754
759
|
<%= define_grid(@tasks_grid, show_filters: :always) do |g|
|
755
760
|
|
@@ -783,24 +788,23 @@ Then, use <tt>grid_filter(grid, :some_filter_name)</tt> to render filters:
|
|
783
788
|
<%= grid(@tasks_grid) %>
|
784
789
|
|
785
790
|
|
786
|
-
Finally, use <tt>render_grid(@grid)</tt> to actually output the grid table
|
791
|
+
Finally, use <tt>render_grid(@grid)</tt> to actually output the grid table.
|
787
792
|
|
788
793
|
|
789
|
-
Using custom submit and reset buttons together with <tt
|
790
|
-
|
791
|
-
|
794
|
+
Using custom submit and reset buttons together with <tt>hide_submit_button: true</tt> and
|
795
|
+
<tt>hide_reset_button: true</tt> allows to completely get rid of the default filter row and the default
|
796
|
+
icons (see section 'Submit/Reset Buttons').
|
792
797
|
|
793
798
|
|
794
|
-
If a column was declared with <tt>:detach_with_id</tt>, but never output with +grid_filter+,
|
795
|
-
|
796
|
-
There is no such message in production.
|
799
|
+
If a column was declared with <tt>:detach_with_id</tt>, but never output with +grid_filter+, filtering
|
800
|
+
the grid in development mode will result in an warning javascript message and the missing filter will be
|
801
|
+
ignored. There is no such message in production.
|
797
802
|
|
798
803
|
|
799
804
|
=== Defining your own external filter processors
|
800
805
|
|
801
806
|
|
802
|
-
It possible to define and use your own column processors outside of the plugin, in
|
803
|
-
you application.
|
807
|
+
It possible to define and use your own column processors outside of the plugin, in you application.
|
804
808
|
|
805
809
|
The first step is to edit <tt>Wice::Defaults::ADDITIONAL_COLUMN_PROCESSORS</tt> in
|
806
810
|
<tt>wice_grid_config.rb</tt>:
|
@@ -827,8 +831,8 @@ The structure of these two classes is as follows:
|
|
827
831
|
|
828
832
|
def yield_declaration_of_column_filter
|
829
833
|
{
|
830
|
-
:
|
831
|
-
:
|
834
|
+
templates: [...],
|
835
|
+
ids: [...]
|
832
836
|
}
|
833
837
|
end
|
834
838
|
end
|
@@ -861,8 +865,8 @@ whose value is the name of the grid:
|
|
861
865
|
<button class="wg-external-submit-button" data-grid-name="grid">Submit</button>
|
862
866
|
<button class="wg-external-reset-button" data-grid-name="grid">Reset</button>
|
863
867
|
|
864
|
-
To hide the default icons use <tt
|
865
|
-
<tt
|
868
|
+
To hide the default icons use <tt>hide_submit_button: true</tt> and
|
869
|
+
<tt>hide_reset_button: true</tt> in the +grid+ helper.
|
866
870
|
|
867
871
|
|
868
872
|
|
@@ -920,7 +924,7 @@ string output whole the second is a hash of HTML attributes to be added for the
|
|
920
924
|
|
921
925
|
g.column do |portal_application|
|
922
926
|
css_class = portal_application.public? ? 'public' : 'private'
|
923
|
-
[portal_application.name, {:
|
927
|
+
[portal_application.name, {class: css_class}]
|
924
928
|
end
|
925
929
|
|
926
930
|
For adding classes/styles to <tt><TR></tt> use special clause +row_attributes+ ,
|
@@ -929,7 +933,7 @@ similar to +column+, only returning a hash:
|
|
929
933
|
<%= grid(@versions_grid) do |g|
|
930
934
|
g.row_attributes do |version|
|
931
935
|
if version.in_production?
|
932
|
-
{:
|
936
|
+
{style: 'background-color: rgb(255, 255, 204);'}
|
933
937
|
end
|
934
938
|
end
|
935
939
|
|
@@ -961,8 +965,8 @@ This works similar to +row_attributes+, by adding blocks +after_row+, +before_ro
|
|
961
965
|
content_tag(:tr,
|
962
966
|
content_tag(:td,
|
963
967
|
'Last row',
|
964
|
-
:
|
965
|
-
:
|
968
|
+
colspan: 10),
|
969
|
+
class: 'last_row')
|
966
970
|
end
|
967
971
|
|
968
972
|
.......
|
@@ -998,7 +1002,7 @@ There are two alternative ways to do the same, submitting a string to +blank_sla
|
|
998
1002
|
|
999
1003
|
Or a partial:
|
1000
1004
|
|
1001
|
-
g.blank_slate :
|
1005
|
+
g.blank_slate partial: "partial_name"
|
1002
1006
|
|
1003
1007
|
|
1004
1008
|
== Action Column
|
@@ -1008,7 +1012,7 @@ for example, deleting selected records. Please note that +action_column+ only cr
|
|
1008
1012
|
'Select All' and 'Deselect All' buttons, and the form itself as well as processing the parameters should be
|
1009
1013
|
taken care of by the application code.
|
1010
1014
|
|
1011
|
-
<%= grid(@tasks_grid, :
|
1015
|
+
<%= grid(@tasks_grid, show_filters: :always) do |g|
|
1012
1016
|
|
1013
1017
|
...
|
1014
1018
|
|
@@ -1025,7 +1029,7 @@ By default the name of the HTTP parameter follows pattern <tt>"#{grid_name}[#{pa
|
|
1025
1029
|
You can hide a certain action checkbox if you add the usual block to +g.action_column+, just like with the
|
1026
1030
|
+g.column+ definition. If the block returns +nil+ or +false+ no checkbox will be rendered.
|
1027
1031
|
|
1028
|
-
<%= grid(@tasks_grid, :
|
1032
|
+
<%= grid(@tasks_grid, show_filters: :always) do |g|
|
1029
1033
|
|
1030
1034
|
...
|
1031
1035
|
|
@@ -1054,11 +1058,11 @@ WiceGrid allows to keep the status of the grid with all the filtering and sortin
|
|
1054
1058
|
all current sorting and filtering parameters as hidden fields. Just include
|
1055
1059
|
<tt>dump_filter_parameters_as_hidden_fields(@grid)</tt> inside your form, and the newly rendered grid will keep ordering and filtering.
|
1056
1060
|
|
1057
|
-
<% form_tag('', :
|
1061
|
+
<% form_tag('', method: :get) do %>
|
1058
1062
|
<%= dump_filter_parameters_as_hidden_fields(@tasks_grid) %>
|
1059
1063
|
<%= select_tag 'archived',
|
1060
1064
|
options_for_select([['View active tasks', 0], ['View archived tasks', 1]], @archived ? 1 : 0),
|
1061
|
-
:
|
1065
|
+
onchange: 'this.form.submit()' %>
|
1062
1066
|
<% end -%>
|
1063
1067
|
|
1064
1068
|
|
@@ -1067,7 +1071,7 @@ all current sorting and filtering parameters as hidden fields. Just include
|
|
1067
1071
|
|
1068
1072
|
It is possible to switch to the All Records mode clicking on link "show all" in the bottom right corner.
|
1069
1073
|
This functionality should be used with care. To turn this mode off for all grid instances,
|
1070
|
-
change constant +
|
1074
|
+
change constant +ALLOW_SHOWING_ALL_RECORDS+ in <tt>config/initializers/wice_grid_config.rb</tt> to
|
1071
1075
|
+false+. To do so for a specific grid, use initializer parameter <tt>:allow_showing_all_records</tt>.
|
1072
1076
|
|
1073
1077
|
Configuration constant +START_SHOWING_WARNING_FROM+ sets the threshold number of all records after
|
@@ -1311,6 +1315,11 @@ only under certain circumstances:
|
|
1311
1315
|
|
1312
1316
|
== Icons
|
1313
1317
|
|
1314
|
-
Icons used by the plugin are courtesy of Mark James, the creator of the SILK icon set
|
1315
|
-
|
1318
|
+
Icons used by the plugin are courtesy of Mark James, the creator of {the SILK icon set}[http://www.famfamfam.com/lab/icons/silk/].
|
1319
|
+
|
1320
|
+
== Bug reports
|
1321
|
+
|
1322
|
+
The author of the plugins welcomes any contribution.
|
1323
|
+
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.
|
1324
|
+
|
1316
1325
|
|