mediawiki-extensions-Discus.../modules/dt.ui.ReplyWidgetVisual.js

102 lines
3 KiB
JavaScript
Raw Normal View History

var
controller = require( 'ext.discussionTools.controller' ),
modifier = require( 'ext.discussionTools.modifier' ),
CommentTargetWidget = require( './CommentTargetWidget.js' );
/**
* DiscussionTools ReplyWidgetVisual class
*
* @class mw.dt.ReplyWidgetVisual
* @extends mw.dt.ReplyWidget
* @constructor
* @param {Object} comment Parsed comment object
* @param {Object} [config] Configuration options
*/
function ReplyWidgetVisual( comment, config ) {
// Parent constructor
ReplyWidgetVisual.super.call( this, comment, config );
}
/* Inheritance */
OO.inheritClass( ReplyWidgetVisual, require( 'ext.discussionTools.ReplyWidget' ) );
/* Methods */
ReplyWidgetVisual.prototype.createReplyBodyWidget = function ( config ) {
return new CommentTargetWidget( $.extend( {
defaultMode: 'source'
}, config ) );
};
ReplyWidgetVisual.prototype.getValue = function () {
return this.replyBodyWidget.target.getSurface().getModel().getDom();
};
ReplyWidgetVisual.prototype.clear = function () {
// Parent method
ReplyWidgetVisual.super.prototype.clear.apply( this, arguments );
this.replyBodyWidget.clear();
};
ReplyWidgetVisual.prototype.isEmpty = function () {
var surface = this.replyBodyWidget.target.getSurface();
return !surface || !surface.getModel().hasBeenModified();
};
ReplyWidgetVisual.prototype.setup = function () {
// Parent method
ReplyWidgetVisual.super.prototype.setup.call( this );
this.replyBodyWidget.setDocument( '<p></p>' );
this.mode = this.replyBodyWidget.target.getSurface().getMode();
// Events
this.replyBodyWidget.target.getSurface().getModel().getDocument().connect( this, { transact: this.onInputChangeThrottled } );
this.replyBodyWidget.target.getSurface().connect( this, { submit: 'onReplyClick' } );
};
ReplyWidgetVisual.prototype.focus = function () {
var targetWidget = this.replyBodyWidget;
setTimeout( function () {
targetWidget.getSurface().getModel().selectLastContentOffset();
targetWidget.focus();
} );
};
ReplyWidgetVisual.prototype.setPending = function ( pending ) {
ReplyWidgetVisual.super.prototype.setPending.call( this, pending );
if ( pending ) {
// TODO
// this.replyBodyWidget.pushPending();
this.replyBodyWidget.setReadOnly( true );
} else {
// this.replyBodyWidget.popPending();
this.replyBodyWidget.setReadOnly( false );
}
};
Pick reply insertion point based on parser tree, not DOM tree I don't like that I had to special-case `<p>` tags (top-level comments) in this code. I feel like it should be possible to handle top-level comments and replies in a generic way, but I couldn't find a way to do it that actually worked. Notes about changes to the behavior, based on the test cases: * Given a top-level comment A, if there was a "list gap" in the replies to it: previously new replies would be incorrectly added at the location of the gap; now they are added after the last reply. (T242822) Example: "pl", comment at "08:23, 29 wrz 2018 (CEST)" * Given a top-level comment A and a reply to it B that skips an indentation level: previously new replies to A would be added with the same indentation level as B; now they are added with the indentation level of A plus one. (The old behavior wasn't a bug, and this is an accidental effect of other changes, but it seems okay.) Example: "pl", comment at "03:22, 30 wrz 2018 (CEST)" and reply at "09:43, 30 wrz 2018 (CEST)" * Given a top-level comment A, a reply to it B, and a following top-level comment C that starts at the same indentation level as B: previously new replies to A would be incorrectly added in the middle of the comment C, due to the DOM list structure; now they are added before C. (T241391) (It seems that comment C was supposed to be a multi-line reply that was wrongly indented. Unfortunately we have no way to distinguish this case from a top-level multi-line comment that just happens to start with a bullet list.) Example: "pl", comments at "03:36, 24 paź 2018 (CEST)", "08:35, 24 paź 2018 (CEST)", "17:14, 24 paź 2018 (CEST)" * In the "en" example, there are some other changes where funnily nested tags result in slightly different results with the new code. They don't look important. * In rare cases, we must split an existing list to add a reply in the right place. (Basically add `</ul>` before the reply and `<ul>` after, but it's a bit awkward in DOM terms.) Example: split-list.html, comment "aaa"; also split-list2.html (which is the result of saving the previous reply), comment "aaa" * The modifier can no longer generate DOM that is invalid HTML, fixing a FIXME in modifier.test.js (or at least, it doesn't happen in these test cases any more). Bug: T241391 Bug: T242822 Change-Id: I2a70db01e9a8916c5636bc59ea8490166966d5ec
2020-01-15 06:09:13 +00:00
ReplyWidgetVisual.prototype.insertNewNodes = function ( newParsoidItem ) {
var wikitext,
surface = this.replyBodyWidget.getSurface();
if ( surface.getMode() === 'source' ) {
wikitext = controller.autoSignWikitext( this.getValue() );
Pick reply insertion point based on parser tree, not DOM tree I don't like that I had to special-case `<p>` tags (top-level comments) in this code. I feel like it should be possible to handle top-level comments and replies in a generic way, but I couldn't find a way to do it that actually worked. Notes about changes to the behavior, based on the test cases: * Given a top-level comment A, if there was a "list gap" in the replies to it: previously new replies would be incorrectly added at the location of the gap; now they are added after the last reply. (T242822) Example: "pl", comment at "08:23, 29 wrz 2018 (CEST)" * Given a top-level comment A and a reply to it B that skips an indentation level: previously new replies to A would be added with the same indentation level as B; now they are added with the indentation level of A plus one. (The old behavior wasn't a bug, and this is an accidental effect of other changes, but it seems okay.) Example: "pl", comment at "03:22, 30 wrz 2018 (CEST)" and reply at "09:43, 30 wrz 2018 (CEST)" * Given a top-level comment A, a reply to it B, and a following top-level comment C that starts at the same indentation level as B: previously new replies to A would be incorrectly added in the middle of the comment C, due to the DOM list structure; now they are added before C. (T241391) (It seems that comment C was supposed to be a multi-line reply that was wrongly indented. Unfortunately we have no way to distinguish this case from a top-level multi-line comment that just happens to start with a bullet list.) Example: "pl", comments at "03:36, 24 paź 2018 (CEST)", "08:35, 24 paź 2018 (CEST)", "17:14, 24 paź 2018 (CEST)" * In the "en" example, there are some other changes where funnily nested tags result in slightly different results with the new code. They don't look important. * In rare cases, we must split an existing list to add a reply in the right place. (Basically add `</ul>` before the reply and `<ul>` after, but it's a bit awkward in DOM terms.) Example: split-list.html, comment "aaa"; also split-list2.html (which is the result of saving the previous reply), comment "aaa" * The modifier can no longer generate DOM that is invalid HTML, fixing a FIXME in modifier.test.js (or at least, it doesn't happen in these test cases any more). Bug: T241391 Bug: T242822 Change-Id: I2a70db01e9a8916c5636bc59ea8490166966d5ec
2020-01-15 06:09:13 +00:00
wikitext.split( '\n' ).forEach( function ( line, i ) {
if ( i > 0 ) {
newParsoidItem = modifier.addSiblingListItem( newParsoidItem );
}
newParsoidItem.appendChild( modifier.createWikitextNode( line ) );
} );
} else {
// TODO: Support multi-line comments in visual mode
newParsoidItem.innerHTML = surface.getHtml();
newParsoidItem.children[ 0 ].appendChild( modifier.createWikitextNode( ' ~~~~' ) );
}
};
module.exports = ReplyWidgetVisual;