Last modified: 2012-02-19 16:16:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25850, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23850 - Include subpages of Common.js to Common.js
Include subpages of Common.js to Common.js
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.16.x
All All
: Lowest enhancement (vote)
: ---
Assigned To: Michael Dale
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-08 21:05 UTC by Nux
Modified: 2012-02-19 16:16 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nux 2010-06-08 21:05:54 UTC
Currently there is a missleading message on any subpage of Common.js e.g. [[MediaWiki:Common.js/abc]]. BUT! I wouldn't like to see this fixed, but see this come true :-).

If all of the subpages of Common.js would get auto included for users it would greatly ease adding new modules.
It would then be logical (and possible) to combine this scripts into one file and might lower server load.
Comment 1 Platonides 2010-06-08 21:10:06 UTC
The message is not completely wrong, since it would be loaded for users with language "abc" if it wasn't a content language.

And no, autoincluding all subpages won't happen. I'd love to be able of doing javascript inclusion, though.
Comment 2 Platonides 2010-06-08 21:10:33 UTC
> language "abc" if it wasn't a content language.

a content *message*.
Comment 3 Roan Kattouw 2010-06-08 21:54:12 UTC
(In reply to comment #1)
> And no, autoincluding all subpages won't happen. I'd love to be able of doing
> javascript inclusion, though.
You mean like importScript()?

Closing as WONTFIX per comment #1.
Comment 4 Michael Dale 2010-06-08 23:49:41 UTC
In response to Nux, there is work underway to support what your getting at. Although the specific of transclution in js space won't happen.  

The scriptloader would let you include use a line in your common.js like: 

if( wgPageName == 'somePageThatNeedsMyModule' ){
    mw.load( 'Some', 'Dependencies', 'WT:MediaWik:Mw.MyModule.js'){
        // Your module is now available
        var MyModule = new mw,MyModule( { /* MyWikiConfigForMyModule */ }
        MyModule.updateUI();
    });
}

This way a single top level script contains all the configuration and included modules for a given wiki and any module set used in a given context is requested as a single package of javascript and css. 

If multiple modules are used in a given context your loader call could include both modules 

Some documentation was generated per gadget usage of this system in bug 23809
Comment 5 Nux 2010-06-09 07:28:18 UTC
OK. I can see [[MediaWiki:Common.js/abc]] might be a problem (as in comment #1), but what about pages like [[MediaWiki:Common.js/My module.js]] or to be more exact MediaWiki:Common.js/*.js?

Also note that importScript makes clearing browser cache very problematic (or almost impossible if you have importScript inside imported script)... Or will mw.load solve this too? Besides if it would compress modules then it would make thing even worse (JS compression in Open Source is IMHO just evil, sorry).
Comment 6 Michael Dale 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.
Comment 7 Helder 2012-02-19 16:16:08 UTC
(In reply to comment #0)
> Currently there is a missleading message on any subpage of Common.js e.g.
> [[MediaWiki:Common.js/abc]].

See also bug 31560.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links