AJAX pager

Write it.
If it's well written, falling back cleanly with no javascript, and something that can be disabled, then I'm sure it will be considered.

Sorry...
Are there problems with writing a pager in AJAX, or it's important only for me? :)

I'd be very interested in an AJAX pager and think it would be a great addition to the jstools module. I could possibly help with some of the development as well, keep me posted.

There are several existing jQuery-based "infinite scroll" plugins. I would be very much in favor of a module that made it possible to drop-in one of those and have all table pagers become infinite scroll instead.

http://drupal.org/node/145551
IMHO this must be done, before anybody starts working on it :)

For ideas, see the implementation in dynamicload.js in the dynamicload module, part of Javascript Tools. Specifically, pagers can be made to load dynamically by calling the method Drupal.dynamicloadPager.

The main limitation of the approach in dynamicload is that it assumes there is a single pager on a page and that loaded content should replace the current content of the main content area. This is appropriate in some cases, but in others will lead to broken results, e.g., when a pager is part of a panel's content and the expected result is that only that panel's content is replaced.

Here's a patch that introduces AJAX paging with an initial implementation for comments. The throbber-active.gif file goes in misc/.

Approach is:
* wrap paged output in a div that includes an ID for the pager data
* js attaches to link elements in pager div
* AJAX call passes pager data ID
* Rendering tests for this ID in the request and, if set, returns JSON

nitfty - subscribe.

works this files with D6 too ?

bookmark.

@Babalu: Nope, D7 only.

Here's a refinement. A problem with the previous patch version was that it explicitly called exit() to terminate the request. This version introduces a new menu constant, MENU_OUTPUT_COMPLETE, that can be returned to indicate that rendering is complete. This constant is returned from comment_render() if rendering was done in JSON. node_show() tests for this return value and, if found, returns the menu item request without further rendering.

In the previous patch I tried to reuse the Drupal.collapseScrollIntoView method to scroll to the newly loaded pager content but it didn't work. Removed here.

Well, already you can omit return (or explicitly return NULL) to omit the theme page call. if ($comments == MENU_OUTPUT_COMPLETE) feels like a tremendous hack to me. How can comments be a menu constant...

@chx: good point. Reroll returning NULL.

Adding back scrolling through a simple Drupal.scrollTo() method to scroll the window to the specified element. This should make for better usability--user is scrolled to the new items (in this case, comments) when they arrive.

See this blog post for more detail on the approaches in this patch: http://www.civicactions.com/blog/AJAX_pagers_Drupal_7

Doesn't Views 2 implement an Ajax pager? Can't we build off of that?

Good question. Some explanation:

This patch indeed draws on the one I did for Views 2, but with one important difference. Views 2 exposes a separate callback for AJAX requests, while this patch uses a single callback for both AJAX and non-AJAX requests.

We took that direction in Views for several reasons: 1. views needs to enable AJAX previews, which were already coded for; 2. views may need to be loaded at other than the regular page path (e.g., when views are on a block); 3. the same AJAX loading was needed for multiple purposes--pagers, exposed filters, and more.

So, while drawing on the previous work for Views, I don't think those reasons apply here, and I think it's cleanest to use a single callback rather than introducing a new one custom each time we need AJAX.

I feel mixed. This patch feels pretty limited, but the attempts to provide a more general solution are all bogged down, so maybe limited is the right approach.

I see this patch as a concrete step toward just those general issues. Sometimes it helps to see the general through the specific.

We have two basic options when implementing AJAX fetching of JSON. One is to provide special callbacks for the AJAX request. That's what I'm trying to avoid in this patch.

The other is to provide a way to use the regular callback to retrieve the specific content requested. Since any number of possible requests could be made at a given path, it's not enough to be able to request "JSON". Rather, we need to make a request like "give me the comment pager results for this node matching these parameters".

For this, I think we need all of the elements in this patch.

Some review of the patch itself would be great. What if anything is missing? How well does this move forward the general problem of enabling more flexible content requests? If there are specific issues with the patch, what are they? How could they be addressed?

The last submitted patch failed testing.

I'd like to give this a review. Although it might just be more work than it needs to be, the ahah.js file has the ability to work on things other than forms (like the pager links) if the necessary Drupal.settings are added manually. While code reuse is great, at the same time it's nice to have things self contained in JavaScript, especially since we don't yet have JS testing suites.

⁣

I wonder how much more of Views' functionality we want to duplicate instead of working on Views-in-core.

Are there no chances whatsoever to put this into 6.x?

None in core whatsoever. But Views has a very nice ajax pager in contrib, on which this is based anyway.

Is this possible that using Views I could implement this ajax pager into topics at forum?