Add support for Pjax about django-endless-pagination HOT 4 OPEN

Suggestions and opinions are welcome!

from django-endless-pagination.

But pjax only works for pushing states, isn't it? I mean, not replacing them.
As I wrote in #24, pushing the new URL to the history can be very annoying when dealing with pages.

Here is a real-life example of what I made with such a behaviour: http://dezede.org/evenements/.
Scroll a few pages, then come back using your browser previous button. You will see all the "pages" you scrolled before coming back to this issue. I find this annoying.

But it could be even more annoying: in my opinion, django-endless-pagination should behave like http://failblog.cheezburger.com/ (except for the URL pattern that sould be ?page=3 or #page=3). As we scroll down or up, the URL follows us. By using pjax, the previous button would follow all the way backwards.

Plus, pjax is restricted to the browser supporting history.pushState.

So I vote for history.js and its replaceState.

EDIT: I changed the behaviour of http://dezede.org/evenements/ from pushState to replaceState.

from django-endless-pagination.

Hi Bertrand,

thanks for your analysis and suggestions. I agree, history.js seems to be the better approach to this problem.
IIUC, we should use replaceState for Twitter-style pagination and pushState for Digg-style.
I like how this feature is implemented in failblog, and we need to address several issues:

1. how to activate this functionality (it could be just an option passed to $.endlessPaginate), and how to handle history.js inclusion;
2. how to switch push/replace state based on the pagination style (it could be trivial);
3. how to annotate scroll position so that we can fire some kind of event that replaces the state when scrolling back;
4. how to deal with multiple pagination in the same page: we need to replace/push the state including the querystring fragments for each pagination in the page.
5. handle fallbacks for html4 browsers (optional?)

Surely I am missing something, but, if this list makes sense, implementing 1 and 2 could be considered a first valuable incremental step. 3, 4 and 5 could be considered (each one) follow-on steps, to be discussed and addressed in separate bugs.

Consider that this feature is not scheduled for inclusion in v2.0. I'd like to release endless pagination soon.

from django-endless-pagination.

Hello @frankban,

Yesterday I implemented a solution to the 3rd issue on this page: http://afo.dezede.org/evenements/. As you can see, the page number in the URL is automatically updated as we scroll down and up.
The javascript source is available here. I had to add a page class and a data-page attribute to each page, as you can see here.

To do this, I used two small libraries: jquery-query and jquery-dotimeout. I used the HTML5 window.history instead of history.js. Besides, I'm sure we'll find a solution to the 1st issue while developping this whole functionality.

2nd issue is trivial in my opinion.

The 4th issue is a little more complicated. I guess we will have to use a <div id="{{ paginator_id }}"> wrapper, where paginator_id is the using kwarg of the paginate template tag. Instead of iterating over .page elements like I did, we would iterate over #paginator_id .page elements for each paginator_id.

The 5th issue is, of course, very tricky. The best thing to do IMHO is to automatically disable ajax paginations on old browsers, and fallback to a non-ajax Digg pagination style. You know, because old browsers with no history API usually already have trouble with ajax.
This would requires some work, but I truly think that would be the best.

from django-endless-pagination.