Calling Pagination Users

Hey guys,

As rails 2.0 approaches, pagination will be removed from rails core
and delegated to a plugin. One of the reasons for this is that no
one on the core team uses pagination on a regular basis. Rather than
just create a plugin in our repository containing the old code, it
would be nice if there were a plugin maintained by someone passionate
about pagination, which can add cool new functionality, while
remaining backwards compatible with the old code, at least for a
while.

So if you're a pagination user, are you using any pagination-related
plugins? Are there any clear leaders in this space?

Michael Koziarski wrote:

So if you're a pagination user, are you using any pagination-related
plugins? Are there any clear leaders in this space?

I've been using this one: http://codefluency.com/2007/3/27/paginator. It is not Rails specific but integrates nicely. Comes as a gem.

Is this a drop in replacement for Rails' pagination?

Recommended replacement?

Hunter Hillegas wrote:

Is this a drop in replacement for Rails' pagination?

Recommended replacement?

No, this is not a drop in. For one, there are no view helpers, just the pagination logic.

The main advantage of Paginator is that it is model agnostic: you can paginate anything you want with it. All you need to know is the total number of records.

It is the best one I have found, but there may be better alternatives out there. I am also waiting to see what this thread turns out.

I think will_paginate is good stuff. Its simple and clean, and I'm
the support should be good since its from the err guys:

http://errtheblog.com/post/929

Its not a drop in replacement, but core pagination had too much magic anyways...

- rob

I think will_paginate is good stuff. Its simple and clean, and I’m
the support should be good since its from the err guys

I’d like now to turn your attention to a will_paginate rewrite I had made just recently:

https://idonee.irb.hr/svn_mislav/public/rails/paginate/

Its not a drop in replacement, but core pagination had too much magic anyways…

It didn’t have too much magic, it had too little. It also had too complex API and internal structure. Also, like will_paginate, you always had more than one instance variable to pass around for a single paginated collection.

In my rewrite I eliminated the need for this by keeping all information in a single collection proxy instance. I also made it a bit more configurable and smarter than will_paginate.

My plugin also supports the ActionController::Base#paginate instance method and has unit tests. I have ported all core Pagination unit tests over to my plugin and it passes them all:

https://idonee.irb.hr/svn_mislav/public/rails/paginate/test/finder_test.rb

https://idonee.irb.hr/svn_mislav/public/rails/paginate/test/pagination_test.rb

You can checkout the plugin from SVN and run unit tests without putting it inside an app. It will realize that and use rubygems instead. (BTW, uses sqlite.)

I can mimic the original Pagination API further, but I don’t know if that makes sense. Re-implementing its API would mean re-creating its cruft. I would rather work on more extensive test suite for the current functionality and improve view helpers for link rendering.

So, this plugin is - for now - as close as we can get to original Pagination. The question for all of you is: how close should we go? How much are we ready to break?

Hi Mislav,

So, this plugin is - for now - as close as we can get to original Pagination. The question for all of you is: how close should we go? How much are we ready to break?

Good work! I think the priorities should be:

 a) clean and maintainable implementation

b) robust and extensible functionality, and

c) compatibility with existing behavior

– in that order!

As long as we’re going to 2.0, we might as well cleanup what needs to be cleaned up, and break what we need to in order to save us grief down the road.

–Ernie P.

So, this plugin is - for now - as close as we can get to original
Pagination. The question for all of you is: how close should we go? How much
are we ready to break?

I think this is a two-step process. Step one is to just take exactly
what's currently in Rails and bottle that up as classic_pagination or
something like that. This will allow anyone using what currently is to
migrate to Rails 2. Then, step 2 would be to improve on what is with a
new plugin that can break backwards compatibility.

I think this is a two-step process. Step one is to just take exactly
what's currently in Rails and bottle that up as classic_pagination or
something like that. This will allow anyone using what currently is to
migrate to Rails 2. Then, step 2 would be to improve on what is with a
new plugin that can break backwards compatibility.

We can even make the install hook for classic_pagination print a
warning that this code is a dead end and you should consider upgrading
to something with a vibrant future.

Those are great ideas! Pagination could be easily extracted from core as-is. (That’s what I did with its unit tests before I refactored them.) Users should be warned that it has poor test coverage and that it’s not going to be maintained. And as for “something with a vibrant future”, errfree guys have just given me access to their will_paginate repo after we agreed to collaborate on making the next version of the plugin. We should quickly bring it up to full test coverage and enhance the API even further! Because there will be classic_pagination available I will simply drop support for the legacy API. One thing less to worry about :slight_smile:

-Mislav

Mislav started committing his kickass changes just now, adding tests
and a whole lot more documentation to will_paginate. If anyone wants
to jump on board and offer suggestions / patches / complaints, the
Lighthouse project is perfect:

http://err.lighthouseapp.com/projects/466-plugins/overview

Mislav started committing his kickass changes just now, adding tests
and a whole lot more documentation to will_paginate. If anyone wants
to jump on board and offer suggestions / patches / complaints, the
Lighthouse project is perfect:

http://err.lighthouseapp.com/projects/466-plugins/overview

Nice work guys, great to see pagination on track to being maintained
by passionate users!

if you're willing to also extract and host classic_pagination, it
would seem only fair that it reference will_paginate in the install.

Ticket #8157: http://dev.rubyonrails.org/ticket/8157

Pagination has just been
extracted and hosted
side by side with will_paginate.
Changeset 229
in that repository also fixes
#8176
, #7325,
#7028
, #4113. I marked a bunch of other patches wontfix because we’re removing Pagination anyway.

See the README for classic_pagination: http://require.errtheblog.com/plugins/browser/classic_pagination/README

I just noticed dynamic scaffold code uses pagination. For those who forgot, dynamic scaffolding is also deprecated and pending for removal. Should I update the Pagination removal patch to fix dynamic scaffolding (by manual pagination) or should I just not care?

So what will replace pagination?

The original pagination is extracted to the “classic_pagination” plugin as I stated above. You have the option to use other pagination systems or plugins like “will_paginate” written by errtheblog guys and me.

And what will replace scaffold?

Dynamic scaffolding is also extracted to a plugin. It is removed from Rails core because it is inflexible; scaffold generators are now preferred since you can actually build on them.

Extracted, hosted, improved … everything has been done, but no comments or response whatsoever. Can the core team finally review #8157? Thanks.

Extracted, hosted, improved ... everything has been done, but no comments or
response whatsoever. Can the core team finally review #8157? Thanks.

Sorry, it's been on my plate and I've been travelling.

The patch looks good for trunk, could you add one for release which
deprecates pagination and points them at your plugin?

It's important that users get a warning with the next 1.2.x release,
and that they can simply install the classic_pagination plugin to
avoid getting spammed.