Faster Pagination in Rails

简介:
Faster Pagination in Rails
 
Pagination in Rails has recently surfaced as a hot topic thanks to Kevin Clark's " Thing's you shouldn't be doing in Rails". There seems to be a lot of confusion around the whole issue, no one has offered a definitive reason as to why the default Pagination helpers shouldn't be used, and at the same time there seems to be a consensus among the 'in' people that you should roll your own pagination in your apps. So what's wrong with the default pagination code?
Well, on first look, not much. If you use it correctly Rails will in fact limit your database queries to correct sizes and pages, so no database overhead here. What about the pagination helper itself? Window code? Yes, there does seem to be a problem here! Rails will by default instantiate a number of 'Page' classes and Window classes once you start using the more advanced features of the helper. Now, instantiating 100+ objects for generating 5 links is never a good idea, ok, point taken. But, I think the biggest problem is in fact not the helpers themselves but how the developers use the code. Some will retrieve an entire collection (find all) and then pass it to the paginator to extract the right collection (think paginate_collection), now we are incurring a double overhead - the database query and the additional load on generating the classes. In retrospect, it seems that the helpers are just too powerful, they make it to easy too write inefficient code, and as such it's not that they should be avoided, they should be understood!
Now, how do we solve the problem? Well, an elegant solution is to use something like:  paginating_find. It's a drop-in plugin which will overwrite your default find method  if  you specify the page parameters in your find query. Now, the database side is taken care of, what about the presentation, after all some of those helpers were there for a good reason! Here is a quick extension/helper I came up with to replace the  pagination_links_each to work with paginating_find:
-----------------------------------------------------------------------------
def windowed_pagination_links (pagingEnum, options )
    link_to_current_page = options [ :link_to_current_page ]
    always_show_anchors = options [ :always_show_anchors ]
    padding = options [ :window_size ]
 
    current_page = pagingEnum. page
    html =  ''
 
     #Calculate the window start and end pages 
    padding = padding <  0 ?  0 : padding
    first = pagingEnum. page_exists? (current_page  - padding ) ? current_page - padding :  1
    last = pagingEnum. page_exists? (current_page + padding ) ? current_page + padding : pagingEnum. last_page
 
     # Print start page if anchors are enabled
    html <<  yield ( 1 )  if always_show_anchors  and  not first ==  1
 
     # Print window pages
    first. upto (last )  do |page|
       (current_page == page && !link_to_current_page ) ? html << page : html <<  yield (page )
     end
 
     # Print end page if anchors are enabled
    html <<  yield (pagingEnum. last_page )  if always_show_anchors  and  not last == pagingEnum. last_page
    html
   end
 
It takes the Enum produced by paginating_find and via some simple math (no extra classes instantiated here!) returns control to your block for each link in your window. Ex: 1 ... 5 6 7 8 9 ... 20 - would be produced for page 7 with a window size 2 and anchors (1 and 20) enabled. Here is my  shared/_paginate.rhtml template:
 
-----------------------------------------------------------------------------
<% if collection.page_count != collection.first_page -%>
<div class="pagination">
   <ul>
   <% if collection.previous_page? -%>
          <li class="nextpage">
         <%= link_to '&#171; previous'{ :page => collection.previous_page } %>
     </li>
   <% else -%>
          <li class="disablepage"> &#171; previous </li>
   <% end -%>
 
     <% last_page = 0 -%>
     <% windowed_pagination_links(collection, :window_size => 2, :link_to_current_page => true, :always_show_anchors => true) do |n| -%>
        <% if collection.page == n -%>
             <li class="currentpage"> <%= n %> </li>
        <% else -%>
           <li> <%= "..." if last_page+1 < n %>
            <%= link_to n, :id => params[:id], :page => n %>
           </li>
        <% end -%>
       <% last_page = n -%>
   <% end -%>
 
     <% if collection.next_page? -%>
      <li class="nextpage">
         <%=  link_to 'next &#187;'{ :page => collection.next_page } %>
      </li>
     <% else -%>
       <li class="disablepage"> &#171; next </li>
     <% end -%>
   </ul>
</div>
<% end -%>
Now, add some  css magic and we get:
Pretty (excuse my doodles, I need to configure my tablet), fast and efficient.




本文转自 fsjoy1983 51CTO博客,原文链接:http://blog.51cto.com/fsjoy/94774,如需转载请自行联系原作者
目录
相关文章
|
5月前
|
开发工具 git Python
Python Tricks : Complacent Comma Placement
Python Tricks : Complacent Comma Placement
22 0
构建 Rack-based 框架 (Rails/Grape/Sinatra) 的几个 Tricks
构建 Rack-based 框架 (Rails/Grape/Sinatra) 的几个 Tricks
|
资源调度 JavaScript 前端开发
snowpack 快速开始
snowpack 快速开始
186 0
snowpack 快速开始
|
算法 Java BI
【论文阅读】(2013)A goal-driven approach to the 2D bin packing and variable-sized bin packing problems
【论文阅读】(2013)A goal-driven approach to the 2D bin packing and variable-sized bin packing problems
188 0
【论文阅读】(2013)A goal-driven approach to the 2D bin packing and variable-sized bin packing problems
|
JavaScript Apache Ruby
用 Passenger(mod_rails) 部署 Sinatra
最近写了一些小 app / web service ,因为用不到 rails 那样的大架构和功能,于是尝试了 sinatra。
144 0
用 Passenger(mod_rails) 部署 Sinatra
|
Linux Windows
6 Effective Methods to Learn New Technologies Faster
Technology is always evolving, and developers need to learn new products and languages faster to cope with these changes.
6310 0
6 Effective Methods to Learn New Technologies Faster