Item's page and will_paginate

Question

I have some photos that are split on successive pages through will_paginate plugin. When you open a photo and then return to all photos using a link, you always return to the first page (e.g. the photo is displayed on page 5, you open the photo, click a link to show all photos and expect that you are on page 5 again, but you are on page 1).

Now, is there any method to get the page number to which a photo belongs to?

I tried to pass a GET parameter, but this only works if the user doesn't perform any more actions (e.g. post a comment, edit photo, ecc.).

Nightstick

Answer 1

page = (number_of_records_before_RECORD / number_of_records_per_page) + 1

In other words. If your photo has ID 40 and there are 25 records before (assuming some records have been deleted), with 20 records per page:

page = (25 / 20) + 1 = 2

You can count the number of records before the selected record using Model.count(:conditions => ['id < ?', record.id], :order => 'id'). The right query depends on which sorting filter you apply to that table when listing all objects.

Toponym

This may be a solution, but I wonder why this code isn't implemented by default in the plugin. Maybe because it doesn't make sense to do what I said in terms of performance.. – Nightstick

Because it doesn't really make sense for a broad audience. This isn't a perfect solution but just a workaround for your specific need. Also, will_paginate provide pagination facilities, not additional ActiveRecord functionalities. – Toponym

I wouldn't have thought it would be a huge performance hit. When you're using a pagination library it will count all of the things you are paging to get the total page count. Provided the column you are ordering on is indexed correctly then it shouldn't be too painful to get a similar count to find the current page. – Trimmer

It's also worth, if you can, doing the count to find the current page in the same transaction as the query to find the items in the page - otherwise a user may find themselves at a page which doesn't have the photo they were expecting on because the number of photos has changed between queries. – Trimmer

I agree wutg Shadwell, this is the reason why I commented "This isn't a perfect solution but just a workaround for your specific need" and one of the best reason why this doesn't really make sense in will_paginate. If you want such this feature, you should code it in the way it best fits your application and requirements. – Toponym

Practically you said to pass back to the gallery something like a GET parameter containing the ID of the photo from which the user comes from, and from that retrieve the current page. Or maybe you said to use a cookie to store the ID of the photo along with the search query? I can't really understand what you suggested.. – Nightstick

You don't need to pass the ID neither via GET nor via Cookie because you know that value: it's the ID of the current record. – Toponym

So you simply said to determine the item's page number when I display the single photo. Ok, this is a solution.. but I still need to keep trace of the search query otherwise I won't be able to determine the correct page. Where is the best way to store it? – Nightstick

That formula should be number of records per page and not number of pages, I've submitted an edit. – Babel

Answer 2

The page number is highly dependent on the results of your search. Your search might have 1, 10, or 100 pages depending on the result set and the number of items per page.

Any link to "show all photos" could contain the search and pagination information, using the GET parameters as you've described. Or store and retrieve via a cookie so that the search results persist until the users clears or selects a new search.

Midstream

The problem is that when the user temporary leaves the photo page (for example to modify it) and then tries to return back to show all photos he always returns to the first page :( While I don't think using cookies it is a good thing for SEO. – Nightstick

@Nightstick If you want to reuse search and paginations parameters between requests, then you'll need to persist them somewhere. That's usually what cookies are for. Not sure what impact this would have on SEO. – Midstream

I saw that many photography sites (such as deviantart.com) use cookies to allow users to go back. – Nightstick

Answer 3

Here's another solution: will_paginate just uses query string parameters 'search_field' and 'page'; you can extract these from the Rails params hash. If you keep track of those using session state, you can reapply them in your controller code, when needed.

Exactly how you manage that will depend on your application. In the app I'm working on, the flow is such that I can distinguish between a general context and a member context. The user enters the member context from the member#index page. So I just set session[:member_context] on entry to the member context; e.g. in members#edit. Then, in the members#index, I have the following code:

if session[:member_context]
  @search_field = session[:search_field]
  @page = session[:page]
  # toggle out of member context
  session[:member_context] = nil
else
  @search_field = params[:search_field]
  @page = params[:page]
  # record lastest search in case the user subsequently enters the member context
  session[:search_field] = @search_field
  session[:page] = @page
end
@members = Member.where(<use @search_field>).page(@page)
# and render ...

This works great in my application.

Mukul