https://bugzilla.wikimedia.org/show_bug.cgi?id=23850
Michael Dale <d...@ucsc.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #6 from Michael Dale <d...@ucsc.edu> 2010-06-09 09:14:35 UTC --- Thanks for your interest in addressing these issues. Yes, once things are going through the script-loader its easier to invalidate and update, it checks the revision ID of the text page to form wikitext urls on page renderings. Some tweaks could be made for it to work in the above described context. Javascript transclution even in the mediaWiki namespace is probably not a good idea. If used inline it will promote bad development paradigms. i.e: imagine in js: if( wgPageName == 'Specail:Upload' ){ {{{MediaWiki:Common.js/Upload.js}}} } Even if you just appended ScriptName.js/*.js to all scriptName requests, it does little for modularity over single long file, ( ie invalidates the top level cache on any underlining module change. It does not promote dynamic modules loaded per context, rather promotes large monolithic codebase invoked everywhere. Include subpages of Common.js to Common.js would break with existing conventions of loading where necessary of the existing mediaWiki:common.js files like: if (wgAction == "edit" || wgAction == "submit" || wgPageName == "Special:Upload") //scripts specific to editing pages { importScript("MediaWiki:Common.js/edit.js") } else if (wgPageName == "Special:Watchlist") //watchlist scripts { importScript("MediaWiki:Common.js/watchlist.js") } Furthermore it makes it difficult to isolate and debug a particular script ( if you don't have an integrated way to get at the raw files in isolation.) mw.load bridges both use contexts by supporting direct reference to all the raw files in debug mode and single compressed packaged request in "scriptLoader" mode. JS compression saves a LOT on transport costs. With big javascript packages its a must. The user can always add a &debug or set a preference to get the raw version. No sense in sending hundreds of extra Kilobytes in non-minified javascript to people who will never know the difference other than what seems like slow site as they wait extra seconds for the js to load. If an error is shwoing up in minified version thats ~not~ present in the non-minified version then its an error with the minifier, and we want the minified line number not the source line number. We could include mention of the "debug" url param to request the non-minified in the header of all the js, retaining "open source reference to the code" for anyone that wanted to look at it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l