Refactor paginate's pseudo-lists

Issue #65 new
Mike Orr
created an issue

Paginate has a pseudo-list layer to unify the various collection types (list/tuple, SQLAlchemy query, SQLAlchemy select, custom sequence). This makes it hard to tell what each backend is doing, and how Python's special methods are interacting with the backend, or whether an object is missing a special method and whether it should need it.

Refactor paginate to eliminate the emulated lists. Instead each backend should have a helper class that does its business in a straightforward manner and returns a Page or the data needed to create a Page. The Page itself can remain a list subclass but its data would be static. Also provide a mechanism for users to provide their own helper classes for unsupported collection types, perhaps by passing in a helper instance to the constructor. If not specified, fall back to the built-in helpers, which could either have a boolean method or raise an exception to indicate the collection is incompatible with it.

Comments (1)

  1. Mike Orr reporter

    The top-level constructor could actually be a function, since it would call a helper and return a Page, but it doesn't have to be a Page itself, and it may be more straightforward for it not to be. Of course the external API would have to remain Page for backward compatibility. Unless we implement it as a paginate2 module. Perhaps this would be a good time to make paginate a standalone distribution outside WebHelpers, then it could add helpers for various databases without bloating WebHelpers.

  2. Log in to comment