Refactor pagination logic

[briri]

The pagination logic within the codebase is needlessly complex. The majority of what the paginable concern is trying to do is propagate parameters/state (e.g. search term, page number, etc.) as the user traverses the results in the table. The methods for helping the views and the controllers have also been conflated and placed inside the paginable concern which makes the logic hard to understand since its a mix of logic for rendering HTML and deciphering request parameters for the controller context.

I recently built an new public DMPs page for the DMPTool that needed the pagination and search functionality but also needed to introduce faceting. Rather than trying to add further complexity to the current paginable architecture, I decided to look at the Kaminari gem's latest documentation and build out a new approach.

The result is much simpler and does not require the maintenance of 2 controller methods and 2 views for every scenario. The following examples could be used as the basis of new pagination concern and helper modules (with some refactoring to genericize them a bit):

• Single controller index action (handles the pagination directly but could be moved to a method)
• Method that builds the faceting options based on the content
• Method that handles sorting
• Method that handles the search
• Method that handles the selected facets
• Main index ERB using Rails' content_for helper to inject the faceting partial
• The results partialthat contains the content, sort options and pagination links
• The facet sections and facets themselves