User "Catrope" changed the status of MediaWiki.r93351. Old Status: new New Status: fixme
User "Catrope" also posted a comment on MediaWiki.r93351. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/93351#c20663 Commit summary: AjaxCategories rewrite: Solving syntax problems, performance improvements and applying code conventions: * Replaced sprite image with separate images and letting ResourceLoader embed them with @embed (@embed means 0 http requests, less maintenance, none of the known limitations with sprites, and more readable code (named files rather than pixel offsets) * Many functions were floating in the global namespace (like window.makeCaseInsensitive). A statement ends after a semi-colon(;). All functions declared after "catUrl" were assigned to the window object. I've instead turned the semi-colons back into comma's, merged some other var statements and moved them to the top of the closure. Changed local function declarations into function expressions for clarity. * fetchSuggestions is called by $.fn.suggestions like ".call( $textbox, $textbox.val() )". So the context (this) isn't the raw element but the jQuery object, no need to re-construct with "$(this)" or "$(that)" which is slow and shouldn't even work. jQuery methods can be called on it directly. I've also replaced "$(this).val()" with the value-argument passed to fetchSuggestions which has this exact value already. * Adding more function documentation. And changing @since to 1.19 as this was merged from js2-branch into 1.19-trunk and new features aren't backported to 1.18. * Optimizing options/default construction to just "options = $.extend( {}, options )". Caching defaultOptions is cool, but doesn't really work if it's in a context/instance local variable. Moved it up to the module closure var statements, now it's static across all instances. * In makeSuggestionBox(): Fixing invalid html fragments passed to jQuery that fail in IE. Shortcuts (like '<foo>' and '<foo/>') are only allowed for createElement triggers, not when creating longer fragments with content and/or attributes which are created through innerHTML, in the latter case the HTML must be completely valid and is not auto-corrected by IE. * Using more jQuery chaining where possible. * In buildRegex(): Using $.map with join( '|' ), (rather than $.each with += '|'; and substr). * Storing the init instance of mw.ajaxCategories in mw.page for reference (rather than local/anonymous). * Applied some best practices and "write testable code" ** Moved some of the functions created on the fly and assigned to 'this' into prototype (reference is cheaper) ** Making sure at least all 'do', 'set' and/or 'prototype' functions have a return value. Even if it's just a simple boolean true or context/this for chain-ability. ** Rewrote confirmEdit( .., .., .., ) as a prototyped method named "doConfirmEdit" which takes a single props-object with named valuas as argument, instead of list with 8 arguments. * Removed trailing whitespace and other minor fixes to comply with the code conventions. ** Removed space between function name and caller: "foo ()" => foo()) ** Changing "someArray.indexOf() + 1" into "someArr.indexOf() !== -1". We want a Boolean here, not a Number. ** Renamed all underscore-variables to non-underscore variants. == Bug fixes == * When adding a category that is not already on the page as-is but of which the clean() version is already on the page, the script would fail. Fixed it by moving the checks up in handleCategoryAdd() and making sure that createCatLink() actually returned something. * confirmEdit() wasn't working properly and had unused code (such as submitButton), removed hidden prepending to #catlinks, no need to, it can be dialog'ed directly from the jQuery object without being somewhere in the document. * in doConfirmEdit() in submitFunction() and multiEdit: Clearing the input field after adding a category, so that when another category is being added it doesn't start with the previous value which is not allowed to be added again... Comment: <blockquote> <pre> if ( matchLineBreak ) { categoryRegex += '[ \\t\\r]*\\n?'; </pre> So this could make the regex potentially match a bunch of spaces after the link, but not a line break? That's confusing. Document this if it's intended, or fix it if it's not. </blockquote> This one wasn't addressed. <blockquote> <pre> /** - * Execute or queue an category add + * Execute or queue an category add. + * @param $link {jQuery} + * @param category + * @param noAppend + * @param exists + * @return {mw.ajaxCategories} </pre> The behavior of this function is barely documented, specifically what it does with $link. In fact, a lot of the internal functions are undocumented, and that's only OK if they're doing trivial things. </blockquote> This was addressed somewhat, but the magic that happens when <code>$link</code> is an empty jQuery object still isn't documented. <blockquote> <pre> if ( matches.length > 1 ) { // The category is duplicated. // Remove all but one match for ( var i = 1; i < matches.length; i++ ) { oldText = oldText.replace( matches[i], '' ); } } newText = oldText.replace( categoryRegex, newCategoryString ); </pre> This can produce inconsistent results. Imagine what happens if, for instance, matches[2] === matches[0]. This isn't too bad, it's just weird. Performance also isn't ideal, because the string is searched multiple times. I think it would be more intuitive to do something like <code>var done = false; newText = oldText.replace( categoryRegex, function() { if ( !done ) { done = true; return newCategoryString; } else { return <nowiki>''</nowiki>; } } );</code>. That would also avoid the weirdness and the performance concern I described. </blockquote> This wasn't addressed either. <blockquote> <pre> var infos = reply.query.pages; </pre> This'll cause a JS error if, for some reason, the query element is not present in the response (I'm not sure the API will return such a response in practice; I guess in theory it could happen if there's like a DB error response or something), so program defensively and make sure things exist before you access them. </blockquote> Unaddressed. <blockquote> <pre> summaryHolder = $( '<p>' ) .html( '<strong>' + mw.msg( 'ajax-category-question' ) + '</strong><br/>' + props.actionSummary ); </pre> And here props.actionSummary is unescaped text that's thrown into the HTML, which is scary, as is the fact that the ajax-category-question message is treated as an HTML message for no good reason. </blockquote> actionSummaries (renamed to dialogDescriptions) are now always HTML and escaped properly but 1) this isn't documented anywhere (and it must be, or people will do it wrong in the future) and 2) it doesn't address the issue that the ajax-category-question message is treated as HTML for no good reason. HTML messages should be avoided unless they're needed. _______________________________________________ MediaWiki-CodeReview mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
