rails - mass selection of html table rows with pagination

Question

I want to give user the ability to proceed in a common action for many selected (with checkboxes) items that are displayed in a table with pagination.

I wonder how am I going to keep track of the selected items of a previous table page while user navigates to other table pages via pagination links.

I use kaminari for pagination.

Any ideas?

Answer 1

An approach you could use is a hidden field or just a javascript variable that you update with some javascript whenever the user selects/de-selects an item in the table.

If your page navigation links use AJAX to only update your table and nav links, your page will still contain the hidden field or variable of the selected items. On a table update you will also have to set the selected state on your table items based on what is selected in your hidden field or variable.

Yeah, its not pretty.

You may want to consider some of the client side MV* frameworks for SPA (Single Page Applications) as things can and do get messy pretty quickly with ad-hoc javascript.

The MV* frameworks I am referring to are Backbone, Ember, Angular, Knockout, Batman and so on. Your app essentially becomes a single minified javascript asset, a single minified stylesheet, plus images and client/server is just AJAX/JSON api. These framework provide structure for your client side code and support binding of views into object state and synchronisation to the server.

It is this shift in client side architecture and native mobile apps that has seen more minimalist server side frameworks like Sinatra rise in popularity as frameworks like Rails (and yes I mean Rails 4.0) no longer provides the "rails" or conventions for developing modern web and mobile applications.

Checkout TodoMVC for a comparison of MV* client frameworks and choose one that fits your style and requirements. My pragmatic (and opinionated) choice after a considered look at all the major ones is Backbone.js + Backbone.Marionette + Coffeescript because you simply don't get painted into a corner. No disrespect intended to others.

My advice with MV* frameworks is:

• be very careful with opinionated frameworks that use declarative view templates or have limited or no ability to put logic in templates, or don't support nested/sub templates. Without such features, view composition is a challenge and rendering views that vary based on say user role, or plan/subscription or have a hierarchical structure becomes difficult if not impossible. I've considered the declarative template ideology and I like the theory but reality bites.
• be careful how much control you have over synchronisation with the server. You often need to "side load" related objects and the last thing you want is the old 1 + N SQL query problem being manifested as a 1 + N JSON query problem!

Answer 2

If you are using any form then you can go for multistep form . you can get the idea from

http://railscasts.com/episodes/217-multistep-forms

But please make sure you need to store the form object in session in this approach so if you have let say 500 fields in your form then there is a change of cookie over flow. please take a look on your application and then decide.