mediawiki-extensions-Echo/modules/model/mw.echo.dm.PaginationModel.js

223 lines
5.3 KiB
JavaScript
Raw Normal View History

( function ( mw ) {
/**
* Pagination model for echo notifications pages.
*
* @class
* @mixins OO.EventEmitter
*
* @constructor
* @param {Object} config Configuration object
* @cfg {string} [pageNext] The continue value of the next page
* @cfg {number} [itemsPerPage] The number of items per page
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
* @cfg {number} [currentPageItemCount] The number of items that are in the
* current page. If not given, the initial count defaults to the total number
* of items per page.
*/
mw.echo.dm.PaginationModel = function MwEchoDmPaginationModel( config ) {
config = config || {};
// Mixin constructor
OO.EventEmitter.call( this );
this.pagesContinue = [];
this.itemsPerPage = this.itemsPerPage || 25;
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
this.currentPageItemCount = config.currentPageItemCount || this.itemsPerPage;
// Set initial page
this.currPageIndex = 0;
this.pagesContinue[ 0 ] = '';
// If a next page is given, fill it
if ( config.pageNext ) {
this.setPageContinue( 1, config.pageNext );
}
};
/* Initialization */
OO.initClass( mw.echo.dm.PaginationModel );
OO.mixinClass( mw.echo.dm.PaginationModel, OO.EventEmitter );
/* Events */
/**
* @event update
*
* Pagination information was updated
*/
/* Methods */
/**
* Reset pagination data
*
* @fires update
*/
mw.echo.dm.PaginationModel.prototype.reset = function () {
this.pagesContinue = [];
this.currPageIndex = 0;
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
this.currentPageItemCount = this.itemsPerPage;
this.emit( 'update' );
};
/**
* Set a page index with its 'continue' value, used for API fetching
*
* @param {number} page Page index
* @param {string} continueVal Continue string value
*/
mw.echo.dm.PaginationModel.prototype.setPageContinue = function ( page, continueVal ) {
if ( this.pagesContinue[ page ] !== continueVal ) {
this.pagesContinue[ page ] = continueVal;
this.emit( 'update' );
}
};
/**
* Get the 'continue' value of a certain page
*
* @param {number} page Page index
* @return {string} Continue string value
*/
mw.echo.dm.PaginationModel.prototype.getPageContinue = function ( page ) {
return this.pagesContinue[ page ];
};
/**
* Get the current page index
*
* @return {number} Current page index
*/
mw.echo.dm.PaginationModel.prototype.getCurrPageIndex = function () {
return this.currPageIndex;
};
/**
* Set the current page index
*
* @private
* @param {number} index Current page index
*/
mw.echo.dm.PaginationModel.prototype.setCurrPageIndex = function ( index ) {
this.currPageIndex = index;
};
/**
* Move forward to the next page
*
* @fires update
*/
mw.echo.dm.PaginationModel.prototype.forwards = function () {
if ( this.hasNextPage() ) {
this.setCurrPageIndex( this.currPageIndex + 1 );
this.emit( 'update' );
}
};
/**
* Move backwards to the previous page
*
* @fires update
*/
mw.echo.dm.PaginationModel.prototype.backwards = function () {
if ( this.hasPrevPage() ) {
this.setCurrPageIndex( this.currPageIndex - 1 );
this.emit( 'update' );
}
};
/**
* Get the previous page continue value
*
* @return {string} Previous page continue value
*/
mw.echo.dm.PaginationModel.prototype.getPrevPageContinue = function () {
return this.pagesContinue[ this.currPageIndex - 1 ];
};
/**
* Get the current page continue value
*
* @return {string} Current page continue value
*/
mw.echo.dm.PaginationModel.prototype.getCurrPageContinue = function () {
return this.pagesContinue[ this.currPageIndex ];
};
/**
* Get the next page continue value
*
* @return {string} Next page continue value
*/
mw.echo.dm.PaginationModel.prototype.getNextPageContinue = function () {
return this.pagesContinue[ this.currPageIndex + 1 ];
};
/**
* Set the next page continue value
*
* @param {string} cont Next page continue value
*/
mw.echo.dm.PaginationModel.prototype.setNextPageContinue = function ( cont ) {
this.setPageContinue( this.currPageIndex + 1, cont );
};
/**
* Check whether a previous page exists
*
* @return {boolean} Previous page exists
*/
mw.echo.dm.PaginationModel.prototype.hasPrevPage = function () {
return this.currPageIndex > 0;
};
/**
* Check whether a next page exists
*
* @return {boolean} Next page exists
*/
mw.echo.dm.PaginationModel.prototype.hasNextPage = function () {
return !!this.pagesContinue[ this.currPageIndex + 1 ];
};
/**
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
* Set the number of items in the current page
*
* @param {number} count Number of items
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
* @fires update
*/
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
mw.echo.dm.PaginationModel.prototype.setCurrentPageItemCount = function ( count ) {
if ( this.currentPageItemCount !== count ) {
this.currentPageItemCount = count;
this.emit( 'update' );
}
};
/**
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
* Get the number of items in the current page
*
* @return {number} Number of items
*/
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
mw.echo.dm.PaginationModel.prototype.getCurrentPageItemCount = function () {
return this.currentPageItemCount;
};
/**
* Set the number of items per page
*
* @param {number} count Number of items per page
*/
mw.echo.dm.PaginationModel.prototype.setItemsPerPage = function ( count ) {
this.itemsPerPage = count;
};
/**
* Get the number of items per page
*
* @return {number} Number of items per page
*/
mw.echo.dm.PaginationModel.prototype.getItemsPerPage = function () {
return this.itemsPerPage;
};
} )( mediaWiki );