Will_paginate and remember checkboxes

Rails
1

How can I remeber which checkbox-es was checked or unchecked when I use
paginate (will_paginate). I don’t want to save checked and unchecked
checkboxes (positions) when I change page, but I want to save at the
end, when I choose, what I want.

2

Anka Anka wrote:

How can I remeber which checkbox-es was checked or unchecked when I use
paginate (will_paginate). I don’t want to save checked and unchecked
checkboxes (positions) when I change page, but I want to save at the
end, when I choose, what I want.

save them in session or create temporary record in new table. you can
make unique record by student_id for example. each checkbox must have
unique id or name than previous page or next page.

You can use :

to get back the hash data of your checkbox data values from table.

Reinhart
http://teapoci.blogspot.com

3

Anka,

you may be asking something which puzzled me:

will_paginate builds the search parameters into the page links so that
if the check boxes were included in a search form and submitted, check
box parameter should be included in the page links of the redisplayed
page. All you need to do is to remember to set the check box value
from the params when as the page is displayed again.

It is a bit of magic that I had not seen explicitly described,
although it is implicitly there in the rails cast for simple search
form

Tonypm

4

Anka,

Did you find a solution to this problem?
I am in need of the same solution where my check_box_tags are in a
partial along with the will_paginate link (ajax with lowpro).

<% for select_image in @images %>
<%= check_box_tag “article[image_ids][]”, select_image.id,
@article.images.include?(select_image) %>
<%= link_to image_tag(select_image.public_filename(:thumb)),
image_path(:id => select_image) %>
<% end %>
<%= will_paginate @images, :params => {:image_ids => ???} %>

tonypm,

I am not able to articulate what you are proposing. Are you able to
elaborate more?

5

Can someone help, and explain how to remember checked and unchecked
checkboxes (ids) in params?

6

I try do this, but… but I don’t know, how to pass ids params.
I have something like this:

<%for user in @users%>


<%=h full_user_name(user)%>
<%=check_box_tag “project[user_ids][]”, user.id,
@project.users.include?(user)%>

<%end%>
<%= will_paginate @users, :params => {‘searchtext’ =>
params[:searchtext], ‘project[user_ids]’ => ??? }, :remote => {:update
=> ‘users_div’}%>

I also changed little bit will_paginate using
http://weblog.redlinesoftware.com/2008/1/30/willpaginate-and-remote-links
maybe here is a problem?

So, I can’t help…
Maybe Tonypm can helps little bit more…, Can You Tonypm?

7

HI!! I’m sure you’ve moved on, but if anyone comes in behind me,
here’s a decent, and painless workaround - you need to nullify all
will_paginate links, and manually change them to submit your current
form. Oh, and you need to create a textbox to hold the page, so
will_page will pick it up, and page appropriately

View:

Call SetLinks for onload:

function SetLinks(){
$$(’.pagination a’).each( function(s){ setClickOnA(s) } );
}

function setClickOnA(anchor){
var num = anchor.href.split("=")[1];

Element.observe(anchor, “click”, function() { $(‘page’).value = num;
submitOnlyForm(); } )
anchor.href = “#”
}

function submitOnlyForm(){
document.forms[0].submit();
}

8

Adam wrote:

HI!! I’m sure you’ve moved on, but if anyone comes in behind me,
here’s a decent, and painless workaround - you need to nullify all
will_paginate links, and manually change them to submit your current
form. Oh, and you need to create a textbox to hold the page, so
will_page will pick it up, and page appropriately

View:

Call SetLinks for onload:

function SetLinks(){
$$(’.pagination a’).each( function(s){ setClickOnA(s) } );
}

function setClickOnA(anchor){
var num = anchor.href.split("=")[1];

Element.observe(anchor, “click”, function() { $(‘page’).value = num;
submitOnlyForm(); } )
anchor.href = “#”
}

function submitOnlyForm(){
document.forms[0].submit();
}

Hi Fred

Could you please throw some more light on this , how to achieve the
checkbox persistence and will_paginate problem using this.

If you could give some step by step procedure , it will be a great help.

Thanks in advance
Neetal

9

Hi Anka,

I have discovered (and should have known) that will_paginate is done
over GET which means you lose those checkboxes which are changed as
you change pages because you are unable to POST any params to the
controller. Mislav’s solution was to save the checked IDs in a
cookie, or even a session by talking to the controller with Ajax on
every check/uncheck. I changed my design by implementing a drag & drop
feature which uses POST and didn’t require any cookies or sessions.

If you did want to implement a sessions method you I think you would
have session[:project] = @project in your controller method and then
in your partial you would have something like:

<%=h full_user_name(user)%> <%=check_box_tag "session[:project][user_ids][]", user.id, session[:project].users.include?(user)%>

Although my knowledge is limited, I hope this gets you on the right
track.

10

Hi,

Just noticed that there have been some more posts to this thread.
Some time ago now, I played with different ways of handling controls
on an index view. I have been developing an approach along the way.
I don’t have all the details at my fingertips at the moment, but in
general, I went along the following lines:

Firstly, the simplest approach is to handle your requests with Get.
Then to retain values of controls such as check box values, or select
boxes etc, you just need to ensure that the value of the control is
defined by the params hash.

My first solution was for a radio button and worked like this.

In the controller action

@search_on = params[:search_on] || ‘a’ # gets the value or sets the
default

In the form
Search Name:
<%= radio_button_tag(‘search_on’,‘n’,@search_on==‘n’) %>
Search All Fields:
<%= radio_button_tag(‘search_on’,‘a’,@search_on==‘a’) %>

(You don’t need to assign search in the controller, it can all be
easily done from params in the view)
This is ok for the simple requirements, but I found mapping the fields
into searches can become really tedious.

The next approach I took (which may not be to everyone’s taste) is to
build my search criteria into a new object based on the model being
searched. In this way, the search fields are available for display in
a form for the model itself, which makes handling the fields really
easy.

eg.

The VIEW - (In haml)

  • form_for :quote, @filter, :html=>{:method=>:get, :id=>‘filter’} do |
    form|
    %b Filter By:
    Company
    = text_field_with_auto_complete :quote, :name,
    {:value=>@filter.name, :size=>20}
    %label Created By
    • opt=(((Quote.find :all, :select=>‘distinct created_by’).map {|q|
      q.created_by}).unshift(’’))
      = form.select(:created_by, opt)
      Status
    • opt=(((Quote.find :all, :select=>‘distinct status’).map {|q|
      q.status}).unshift (’’))
      = form.select(:status, opt)
      = submit_tag ‘Search’

In the CONTROLLER index action:

if params[:quote]
@filter=Quote.new(params[:quote])
session[:quote_filter]=@filter
elsif session[:quote_filter]
@filter=session[:quote_filter]
else
@filter=Quote.new(:status=>’’, :converted_to_sale=>‘false’)
end
@quotes = @filter.search params[:page]

@filter is a new record of the quote model that is used to create the
form in the view.
I use the params[:quote] if there is one since this has come from the
view and is the new search criteria.
I save the filter to the session
If there are no params, then I get the filter from the session so that
the last used search is reinstated
In the Quote model, I have a method called search which uses the
params to build the search.

Here is another form using observers to eliminate the submit button.

  • form_for :supply_order, @filter, :url=>’/supply_orders/index’, |
    :html=>{:name=>‘filter_form’, :id=>‘filter_form’} do |form| |
    %b Filter By:
    Order From
    = form.collection_select :supplier_id,
    Contact.suppliers, :id, :name, {:include_blank=>true}
    %label Ordered By:
    =form.select(:ordered_by,SupplyOrder.ordered_by_list)
    = ’ - ’
    %b Complete:
    = form.check_box :complete,{}, checked_value = “1”, unchecked_value
    = “0”
    = observe_field ‘supply_order_supplier_id’, |
    :url=>’/supply_orders/index’, |
    :before => “$
    (”+"‘filter_form’"+").className=‘dirty’;" , |
    :with=>"‘supply_order[supplier_id]=’ + value" |

= observe_field ‘supply_order_ordered_by’, |
:url=>’/supply_orders/index’, |
:before => “$
(”+"‘filter_form’"+").className=‘dirty’;" , |
:with=>"‘supply_order[ordered_by]=’ + value" |

OK so this works for search criteria that exist as fields in the
model, but what if you have one that isn’t in the model. For this
situation, I simply add an attr_accessor to the model for that search
field. I know purists will cringe at using the model in this way, but
it does result in a neat and consistent solution

I hope this may give you some ideas.

Finally, I have now developed an abstracted solution which can be
slotted into any resource. It saves the search in a database model
called Search. I save an entry for each user, serailizing the search
fields into the database and also saving the page number and page
size. All searches are ajax enabled, and I even allow the page size
to be directly edited in the view so you can set your own preference.
The search is handled in the index action by (for model Thing):
@search=Search.set_search(user,Thing,params)
@[email protected]
@[email protected]_search

Search.set gets or creates an entry in the search table for the model/
user.
@filter gets the fields from the current or new search by calling
@search.filter. I have arranged it so that it works using ajax,
updating only one search field at a time. @filter is used to display
the form in the view
@filter.do search handles pagination and calls a search method in the
model to be searched (which needs to be created individually for each
model).

If anyone is interested in more detail, then I could put some notes
together. It is the sort of thing that might make a plugin, but I
don’t have experience in that at the moment, and the whole thing still
needs a bit of cleaning up. If I can get it cleaned up in my apps, I
may try to put some time aside to make it a plugin.

Tonypm