mirror of
https://github.com/kaminari/kaminari.git
synced 2022-11-09 13:44:37 -05:00
331 lines
12 KiB
Text
331 lines
12 KiB
Text
= Kaminari {<img src="https://travis-ci.org/amatsuda/kaminari.png"/>}[http://travis-ci.org/amatsuda/kaminari] {<img src="https://codeclimate.com/github/amatsuda/kaminari.png" />}[https://codeclimate.com/github/amatsuda/kaminari] {<img src="http://inch-pages.github.io/github/amatsuda/kaminari.png" alt="Inline docs" />}[http://inch-pages.github.io/github/amatsuda/kaminari]
|
||
|
||
A Scope & Engine based, clean, powerful, customizable and sophisticated paginator for modern web app frameworks and ORMs
|
||
|
||
|
||
== Features
|
||
|
||
=== Clean
|
||
Does not globally pollute +Array+, +Hash+, +Object+ or <tt>AR::Base</tt>.
|
||
|
||
=== Easy to use
|
||
Just bundle the gem, then your models are ready to be paginated. No configuration required. Don't have to define anything in your models or helpers.
|
||
|
||
=== Simple scope-based API
|
||
Everything is method chainable with less "Hasheritis". You know, that's the Rails 3 way.
|
||
No special collection class or anything for the paginated values, instead using a general <tt>AR::Relation</tt> instance. So, of course you can chain any other conditions before or after the paginator scope.
|
||
|
||
=== Customizable engine-based I18n-aware helper
|
||
As the whole pagination helper is basically just a collection of links and non-links, Kaminari renders each of them through its own partial template inside the Engine. So, you can easily modify their behaviour, style or whatever by overriding partial templates.
|
||
|
||
=== ORM & template engine agnostic
|
||
Kaminari supports multiple ORMs (ActiveRecord, DataMapper, Mongoid, MongoMapper) multiple web frameworks (Rails, Sinatra, Grape), and multiple template engines (ERB, Haml, Slim).
|
||
|
||
=== Modern
|
||
The pagination helper outputs the HTML5 <nav> tag by default. Plus, the helper supports Rails 3 unobtrusive Ajax.
|
||
|
||
|
||
== Supported versions
|
||
|
||
* Ruby 1.8.7, 1.9.2, 1.9.3, 2.0.0, 2.1 (trunk)
|
||
|
||
* Rails 3.0.x, 3.1, 3.2, 4.0, 4.1 (edge)
|
||
|
||
* Haml 3+
|
||
|
||
* Mongoid 2+
|
||
|
||
* MongoMapper 0.9+
|
||
|
||
* DataMapper 1.1.0+
|
||
|
||
== Install
|
||
|
||
Put this line in your Gemfile:
|
||
gem 'kaminari'
|
||
|
||
Then bundle:
|
||
% bundle
|
||
|
||
|
||
== Usage
|
||
|
||
=== Query Basics
|
||
|
||
* the +page+ scope
|
||
|
||
To fetch the 7th page of users (default +per_page+ is 25)
|
||
User.page(7)
|
||
|
||
* the +per+ scope
|
||
|
||
To show a lot more users per each page (change the +per_page+ value)
|
||
User.page(7).per(50)
|
||
Note that the +per+ scope is not directly defined on the models but is just a method defined on the page scope. This is absolutely reasonable because you will never actually use +per_page+ without specifying the +page+ number.
|
||
|
||
Keep in mind that +per+ utilizes internally +limit+ and so it will override any +limit+ that was set previously
|
||
User.count # => 1000
|
||
a = User.limit(5).count # => 5
|
||
b = a.page(1).per(20).size # => 20
|
||
|
||
* the +padding+ scope
|
||
|
||
Occasionally you need to pad a number of records that is not a multiple of the page size.
|
||
User.page(7).per(50).padding(3)
|
||
Note that the +padding+ scope also is not directly defined on the models.
|
||
|
||
=== General configuration options
|
||
|
||
You can configure the following default values by overriding these values using <tt>Kaminari.configure</tt> method.
|
||
default_per_page # 25 by default
|
||
max_per_page # nil by default
|
||
max_pages # nil by default
|
||
window # 4 by default
|
||
outer_window # 0 by default
|
||
left # 0 by default
|
||
right # 0 by default
|
||
page_method_name # :page by default
|
||
param_name # :page by default
|
||
|
||
There's a handy generator that generates the default configuration file into config/initializers directory.
|
||
Run the following generator command, then edit the generated file.
|
||
% rails g kaminari:config
|
||
|
||
* changing +page_method_name+
|
||
|
||
You can change the method name +page+ to +bonzo+ or +plant+ or whatever you like, in order to play nice with existing +page+ method or association or scope or any other plugin that defines +page+ method on your models.
|
||
|
||
|
||
=== Configuring default +per_page+ value for each model
|
||
|
||
* +paginates_per+
|
||
|
||
You can specify default +per_page+ value per each model using the following declarative DSL.
|
||
class User < ActiveRecord::Base
|
||
paginates_per 50
|
||
end
|
||
|
||
=== Configuring max +per_page+ value for each model
|
||
|
||
* +max_paginates_per+
|
||
|
||
You can specify max +per_page+ value per each model using the following declarative DSL.
|
||
If the variable that specified via +per+ scope is more than this variable, +max_paginates_per+ is used instead of it. Default value is nil, which means you are not imposing any max +per_page+ value.
|
||
class User < ActiveRecord::Base
|
||
max_paginates_per 100
|
||
end
|
||
|
||
=== Controllers
|
||
|
||
* the page parameter is in <tt>params[:page]</tt>
|
||
|
||
Typically, your controller code will look like this:
|
||
@users = User.order(:name).page params[:page]
|
||
|
||
=== Views
|
||
|
||
* the same old helper method
|
||
|
||
Just call the +paginate+ helper:
|
||
<%= paginate @users %>
|
||
|
||
This will render several <tt>?page=N</tt> pagination links surrounded by an HTML5 <+nav+> tag.
|
||
|
||
=== Helpers
|
||
|
||
* the +paginate+ helper method
|
||
|
||
<%= paginate @users %>
|
||
This would output several pagination links such as <tt>« First ‹ Prev ... 2 3 4 5 6 7 8 9 10 ... Next › Last »</tt>
|
||
|
||
* specifying the "inner window" size (4 by default)
|
||
|
||
<%= paginate @users, :window => 2 %>
|
||
This would output something like <tt>... 5 6 7 8 9 ...</tt> when 7 is the current page.
|
||
|
||
* specifying the "outer window" size (0 by default)
|
||
|
||
<%= paginate @users, :outer_window => 3 %>
|
||
This would output something like <tt>1 2 3 4 ...(snip)... 17 18 19 20</tt> while having 20 pages in total.
|
||
|
||
* outer window can be separately specified by +left+, +right+ (0 by default)
|
||
|
||
<%= paginate @users, :left => 1, :right => 3 %>
|
||
This would output something like <tt>1 ...(snip)... 18 19 20</tt> while having 20 pages in total.
|
||
|
||
* changing the parameter name (:+param_name+) for the links
|
||
|
||
<%= paginate @users, :param_name => :pagina %>
|
||
This would modify the query parameter name on each links.
|
||
|
||
* extra parameters (:+params+) for the links
|
||
|
||
<%= paginate @users, :params => {:controller => 'foo', :action => 'bar'} %>
|
||
This would modify each link's +url_option+. :+controller+ and :+action+ might be the keys in common.
|
||
|
||
* Ajax links (crazy simple, but works perfectly!)
|
||
|
||
<%= paginate @users, :remote => true %>
|
||
This would add <tt>data-remote="true"</tt> to all the links inside.
|
||
|
||
* the +link_to_next_page+ and +link_to_previous_page+ helper method
|
||
|
||
<%= link_to_next_page @items, 'Next Page' %>
|
||
This simply renders a link to the next page. This would be helpful for creating a Twitter-like pagination feature.
|
||
|
||
* the +page_entries_info+ helper method
|
||
|
||
<%= page_entries_info @users %>
|
||
This renders a helpful message with numbers of displayed vs. total entries.
|
||
|
||
=== I18n and labels
|
||
|
||
The default labels for 'first', 'last', 'previous', '...' and 'next' are stored in the I18n yaml inside the engine, and rendered through I18n API. You can switch the label value per I18n.locale for your internationalized application.
|
||
Keys and the default values are the following. You can override them by adding to a YAML file in your <tt>Rails.root/config/locales</tt> directory.
|
||
|
||
en:
|
||
views:
|
||
pagination:
|
||
first: "« First"
|
||
last: "Last »"
|
||
previous: "‹ Prev"
|
||
next: "Next ›"
|
||
truncate: "…"
|
||
helpers:
|
||
page_entries_info:
|
||
one_page:
|
||
display_entries:
|
||
zero: "No %{entry_name} found"
|
||
one: "Displaying <b>1</b> %{entry_name}"
|
||
other: "Displaying <b>all %{count}</b> %{entry_name}"
|
||
more_pages:
|
||
display_entries: "Displaying %{entry_name} <b>%{first} - %{last}</b> of <b>%{total}</b> in total"
|
||
|
||
=== Customizing the pagination helper
|
||
|
||
Kaminari includes a handy template generator.
|
||
|
||
* to edit your paginator
|
||
|
||
Run the generator first,
|
||
% rails g kaminari:views default
|
||
|
||
then edit the partials in your app's <tt>app/views/kaminari/</tt> directory.
|
||
|
||
* for Haml users
|
||
|
||
Haml templates generator is also available by adding the <tt>-e haml</tt> option (this is automatically invoked when the default template_engine is set to Haml).
|
||
|
||
% rails g kaminari:views default -e haml
|
||
|
||
* themes
|
||
|
||
The generator has the ability to fetch several sample template themes from
|
||
the external repository (https://github.com/amatsuda/kaminari_themes) in
|
||
addition to the bundled "default" one, which will help you creating a nice
|
||
looking paginator.
|
||
% rails g kaminari:views THEME
|
||
|
||
To see the full list of avaliable themes, take a look at the themes repository,
|
||
or just hit the generator without specifying +THEME+ argument.
|
||
% rails g kaminari:views
|
||
|
||
* multiple themes
|
||
|
||
To utilize multiple themes from within a single application, create a directory within the app/views/kaminari/ and move your custom template files into that directory.
|
||
% rails g kaminari:views default (skip if you have existing kaminari views)
|
||
% cd app/views/kaminari
|
||
% mkdir my_custom_theme
|
||
% cp _*.html.* my_custom_theme/
|
||
|
||
Next, reference that directory when calling the +paginate+ method:
|
||
|
||
<%= paginate @users, :theme => 'my_custom_theme' %>
|
||
|
||
Customize away!
|
||
|
||
Note: if the theme isn't present or none is specified, kaminari will default back to the views included within the gem.
|
||
|
||
=== Paginating a generic Array object
|
||
|
||
Kaminari provides an Array wrapper class that adapts a generic Array object to the <tt>paginate</tt> view helper.
|
||
However, the <tt>paginate</tt> helper doesn't automatically handle your Array object (this is intentional and by design).
|
||
<tt>Kaminari::paginate_array</tt> method converts your Array object into a paginatable Array that accepts <tt>page</tt> method.
|
||
|
||
@paginatable_array = Kaminari.paginate_array(my_array_object).page(params[:page]).per(10)
|
||
|
||
You can specify the +total_count+ value through options Hash. This would be helpful when handling an Array-ish object that has a different +count+ value from actual +count+ such as RSolr search result or when you need to generate a custom pagination. For example:
|
||
|
||
@paginatable_array = Kaminari.paginate_array([], total_count: 145).page(params[:page]).per(10)
|
||
|
||
== Creating friendly URLs and caching
|
||
|
||
Because of the +page+ parameter and Rails 3 routing, you can easily generate SEO and user-friendly URLs. For any resource you'd like to paginate, just add the following to your +routes.rb+:
|
||
|
||
resources :my_resources do
|
||
get 'page/:page', :action => :index, :on => :collection
|
||
end
|
||
|
||
This will create URLs like <tt>/my_resources/page/33</tt> instead of <tt>/my_resources?page=33</tt>. This is now a friendly URL, but it also has other added benefits...
|
||
|
||
Because the +page+ parameter is now a URL segment, we can leverage on Rails page caching[http://guides.rubyonrails.org/caching_with_rails.html#page-caching]!
|
||
|
||
NOTE: In this example, I've pointed the route to my <tt>:index</tt> action. You may have defined a custom pagination action in your controller - you should point <tt>:action => :your_custom_action</tt> instead.
|
||
|
||
|
||
== Sinatra/Padrino support
|
||
|
||
Since version 0.13.0, kaminari started to support Sinatra or Sinatra-based frameworks experimentally.
|
||
|
||
To use kaminari and its helpers with these frameworks,
|
||
|
||
require 'kaminari/sinatra'
|
||
|
||
or edit gemfile:
|
||
|
||
gem 'kaminari', :require => 'kaminari/sinatra'
|
||
|
||
This line just enables model-side features, such as <tt>Model#page</tt> and <tt>Model#per</tt>. If you want to use view helpers, please explicitly <tt>register</tt> helpers in your Sinatra or Padrino app:
|
||
|
||
register Kaminari::Helpers::SinatraHelpers
|
||
|
||
Or, you can implement your own awesome helper :)
|
||
|
||
More features are coming, and again, this is still experimental. Please let us know if you found anything wrong with the Sinatra support.
|
||
|
||
|
||
== For more information
|
||
|
||
Check out Kaminari recipes on the GitHub Wiki for more advanced tips and techniques.
|
||
https://github.com/amatsuda/kaminari/wiki/Kaminari-recipes
|
||
|
||
|
||
== Questions, Feedback
|
||
|
||
Feel free to message me on Github (amatsuda) or Twitter (@a_matsuda) ☇☇☇ :)
|
||
|
||
|
||
== Contributing to Kaminari
|
||
|
||
Fork, fix, then send a pull request.
|
||
|
||
To run the test suite locally against all supported frameworks:
|
||
|
||
% bundle install
|
||
% rake spec:all
|
||
|
||
To target the test suite against one framework:
|
||
|
||
% rake spec:active_record_40
|
||
|
||
You can find a list of supported spec tasks by running <tt>rake -T</tt>. You may also find it useful to run a specific test
|
||
for a specific framework. To do so, you'll have to first make sure you have bundled everything for that configuration,
|
||
then you can run the specific test:
|
||
|
||
% BUNDLE_GEMFILE='gemfiles/active_record_40.gemfile' bundle install
|
||
% BUNDLE_GEMFILE='gemfiles/active_record_40.gemfile' bundle exec rspec ./spec/requests/users_spec.rb
|
||
|
||
|
||
== Copyright
|
||
|
||
Copyright (c) 2011 Akira Matsuda. See MIT-LICENSE for further details.
|