Infinite scroll - Bundled Plugin in 1.9

From the this current discussion we learnt two things:

  • It must be a plugin,
  • and the default behaivor must be 'load more' button, not 'automatic scroll'.

1. The plugin

We have the plugin to begin working here: https://github.com/lorea/Infinite-Scroll

Some defects have been detected:

  • Gallery lists are not ajax paginable yet (Enhancement). Fixed: 310a4ec419
  • List are shown inline in Opera (UI, Defect). Worksforme
  • It conflicts with some previous plugins (Defect). Wontfix

And here the feature requests:

  • Use more load button instead of infinite scrolling. Fixed:  71ebf92b99
  • Notice that there are new list items to download from the server.
  • Integrate javascript friendly time to have updated lists.

2. Core modifications

We can think in doing core modifications to make more natural the ajax get of entities. Look the first lines of /views/default/infinite_scroll/list.php and you'll understand what I wanna mean.

3. Steps to follow

Include plugin in 1.9 branch, under the name of ajax_pagination infinite_scroll.

Make a ticket for each defect and feature request, and fix all.

Work the second section and integrate better the plugin into the core, modifying the core if it is necessary.

I will need access to the repo, to make my live easyer coding this plugin. Don't worry, I won't do much craps.

  • Will the plugin replace the old pagination completely and use a "view more"-button as a default in all lists? Will it view the lists in ascending or descending order? So will the button function be "view older messages" on top of the list or "view newer messages" at the end of the list?

    I'm thinking about ways to make urls that would take user directly to a particular page in a paginated entity list and I'm wondering how the ajax pagination would affect it.

    So for example the page...

    www.example.com/view/blog/123/comment/456/

    would display the blog normally but would display the comment pagination page which includes the comment with guid 456.

    With ajax pagination this would propably need a separate button for both the older and the newer messages.

  • @Juho : for that functionality (URL consistency) we have to either go with html5 window.history.pushState() api or the twitter like hash (#) method. We are doing a complete Elgg ajaxification project as per the HTML5 standards. (Its a commercial work, If the client agrees in releasing it to community the members will be lucky to have it)

  • If the ajax pagination that is being planned for Elgg 1.9 won't have an actual pagination (previous, 1, 2, 3, next) but just a button to add more items to the list, the url consistency won't be a problem since the user isn't really moving from a list page to another.

  • @Juho: Our approach is different. We are relying on the standard elgg paginations, filter tabs, links etc  and listening to the onclick() event. This way we can avoid writting a lot of code and avoid duplicating and creating a lot of ajax views. 

  • @Mohammed Is the commercial job somehow related to the ajax pagination that is going to be added to the default Elgg package in 1.9? http://trac.elgg.org/ticket/2596

    I'm only interested in the bundled 1.9 plugin since I'm currently working on rewriting the comments system for Elgg 1.9: http://trac.elgg.org/ticket/2146

  • i don't know whether this has been shared already or not.. 
    i notice that the ajax paginator needs to have a way of being easily extended since we may wish some other page processing to be done via javascript on any items that are loaded into the paginated list via ajax.