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

150 lines
3.8 KiB
JavaScript
Raw Normal View History

( function ( mw ) {
/**
* Cross-wiki notification item model. Contains a list of sources,
* that each contain a list of notification items from that source.
*
* @class
* @extends mw.echo.dm.NotificationItem
*
* @constructor
* @param {number} id Notification id
* @param {Object} [config] Configuration object
* @cfg {number} count The initial anticipated count of notifications through all
* of the sources.
*/
mw.echo.dm.CrossWikiNotificationItem = function MwEchoDmCrossWikiNotificationItem( id, config ) {
config = config || {};
mw.echo.dm.CrossWikiNotificationItem.parent.call( this, id, config );
this.foreign = true;
this.source = null;
this.count = config.count || 0;
this.list = new mw.echo.dm.NotificationGroupsList();
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.list.connect( this, { discard: 'onListDiscard' } );
};
OO.inheritClass( mw.echo.dm.CrossWikiNotificationItem, mw.echo.dm.NotificationItem );
/* Events */
/**
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
* @event discard
* @param {string} name The symbolic name for the list model that was discarded
*
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
* A sub list has been discarded
*/
/* Methods */
/**
* Respond to list being removed from the cross-wiki bundle.
*
* @param {mw.echo.dm.NotificationGroupsList} sourceModel The source model that was removed
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 discard
*/
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.CrossWikiNotificationItem.prototype.onListDiscard = function ( sourceModel ) {
this.emit( 'discard', sourceModel.getName() );
};
/**
* Get the list of sources
*
* @return {mw.echo.dm.NotificationGroupsList} List of sources
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.getList = function () {
return this.list;
};
/**
* Get an array of source names that are in the cross-wiki list
*
* @return {string[]} Source names
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.getSourceNames = function () {
var i,
sourceNames = [],
sourceLists = this.list.getItems();
for ( i = 0; i < sourceLists.length; i++ ) {
sourceNames.push( sourceLists[ i ].getName() );
}
return sourceNames;
};
/**
* Get a specific item from the list by its source name
*
* @param {string} sourceName Source name
* @return {mw.echo.dm.NotificationGroupsList} Source item
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.getItemBySource = function ( sourceName ) {
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
return this.list.getGroupByName( sourceName );
};
/**
* Get expected item count from all sources
*
* @return {number} Item count
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.getCount = function () {
return this.count;
};
/**
* Check if there are unseen items in any of the cross wiki source lists.
* This method is required for all models that are managed by the
* mw.echo.dm.ModelManager.
*
* @return {boolean} There are unseen items
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.hasUnseen = function () {
var i, j, items,
sourceLists = this.getList().getItems();
for ( i = 0; i < sourceLists.length; i++ ) {
items = sourceLists[ i ].getItems();
for ( j = 0; j < items.length; j++ ) {
if ( !items[ j ].isSeen() ) {
return true;
}
}
}
return false;
};
/**
* Get all items in the cross wiki notification bundle
*
* @return {mw.echo.dm.NotificationItem[]} All items across all sources
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.getItems = function () {
var notifications = [];
this.list.getItems().forEach( function ( sourceList ) {
notifications = notifications.concat( sourceList.getItems() );
} );
return notifications;
};
/**
* This item is a group.
* This method is required for all models that are managed by the
* mw.echo.dm.ModelManager.
*
* @return {boolean} This item is a group
*/
mw.echo.dm.CrossWikiNotificationItem.prototype.isGroup = function () {
return true;
};
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.CrossWikiNotificationItem.prototype.isEmpty = function () {
return this.getList().isEmpty();
};
} )( mediaWiki );