Last modified: 2012-03-10 22:04:35 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 T29281, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27281 - Add support in the front-end for loading wiki pages as resources
Add support in the front-end for loading wiki pages as resources
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.18.x
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-09 18:31 UTC by Liangent
Modified: 2012-03-10 22:04 UTC (History)
3 users (show)

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


Attachments

Description Liangent 2011-02-09 18:31:48 UTC
There's no simple way to import scripts in wiki pages with RL, except for building URLs manually. With the deprecation of legacy JS API, a good way to do it in RL is needed. It would be better that it can be done with page revision check as well.

Just an imagination:

1. Several scripts call a function individually:

mw.loader.pageLoad('User:Liangent/Scripts/a.js');
mw.loader.pageLoad('User:Liangent/Scripts/b.js');
mw.loader.pageLoad('User:Liangent/Scripts/c.js');

2. At the end something calls:

mw.loader.pageGo();

3. A <script src="load.php?page[]=User:Liangent/Scripts/a.js&page[]=User:Liangent/Scripts/b.js&page[]=User:Liangent/Scripts/c.js"> is inserted. Make this call non-cachable at browser side, possibly cachable at server side (squid level?) and invalidated on edits of any of .../a.js, b.js or c.js.

4. In its content it imports (minified contents of) .../a.js, b.js and c.js individually, with timestamps or revision ids in URLs and make them permanently cached.
Comment 1 Krinkle 2011-02-14 22:21:55 UTC
Rather than reinventing the loader for wiki pages I think we better ingrate with what we already have.

ie.

mw.loader.wikiLoad( 'User:Liangent/Scripts/a.js' ), which internally will use the same as used for "MediaWiki:Common.js" and "User:Liangent/vector.js"

Regarding mw.loader.pageGo(), you can use an array of modules in mw.loader.load or mw.loader.using.

mw.loader.load( ['jquery.colorUtil', 'jquery.hoverIntent', 'jquery.ui.autocomplete'] );

or:

mw.loader.using( ['jquery.ui.widget', 'jquery.ui.mouse'], function(){
  // do fancy stuff with widgets and mice.
});

both only make 1 http request:
mw.loader.pageLoad( ['User:Liangent/Scripts/a.js', 'User:Liangent/Scripts/b.js', 'User:Liangent/Scripts/c.js'] );

Adding a wikiLoad function I think is a great idea that is a must-have. However, again, it should not map to mw.loader.load( http://.org/w/?title=TITLE&action=raw&ctype=text/javascript); but instead really go to the server and minify it like it would do for User:/vector.js or MediaWiki:Common.js
Comment 2 Liangent 2011-02-15 05:45:26 UTC
(In reply to comment #1)
> mw.loader.wikiLoad( 'User:Liangent/Scripts/a.js' ), which internally will use
> the same as used for "MediaWiki:Common.js" and "User:Liangent/vector.js"

They're loaded as modules=site and modules=user, not something generic.

> Regarding mw.loader.pageGo(), you can use an array of modules in mw.loader.load

Can modules have parameters (to specify the page names) currently?

> However, again, it should not map to mw.loader.load(
> http://.org/w/?title=TITLE&action=raw&ctype=text/javascript);

Actually I don't know why we invented this. There's already jQuery.getScript.
Comment 3 Roan Kattouw 2011-02-15 21:11:01 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > mw.loader.wikiLoad( 'User:Liangent/Scripts/a.js' ), which internally will use
> > the same as used for "MediaWiki:Common.js" and "User:Liangent/vector.js"
> 
> They're loaded as modules=site and modules=user, not something generic.
> 
The backend infrastructure does use a generic interface for loading wiki pages (ResourceLoaderWikiModule.php)
Comment 4 Bugmeister Bot 2011-08-19 19:12:57 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 5 Helder 2012-02-24 11:19:20 UTC
See also:
* Bug 25845 - Support loading wiki pages through mediaWiki.loader.load()
Comment 6 Krinkle 2012-03-10 22:04:21 UTC
(Cited from bug 25845 comment #19)
> mw.loader.load has 2 purposes:
> * On-demand loading of a module registered in ResourceLoader
> * On-demand loading of a raw url
> 
> I think this is a solid system. And loading wiki pages is not a useful feature.
> Instead we should focus on implementing the ability for users to create their
> own complete ResourceLoader modules within their own space. Allowing raw
> loading of wiki pages (although minified) is barely any improvement over the
> current system and doesn't address any of the following issues, which have on
> the contrary been solved in ResourceLoader
>
> * Proper caching
> * Not loading the same content twice (using dependency lists of modules by a
> name instead of direct loading of a script page)
> * Concatenation
> * Translation
> * RTL-support
> * more..
> 
> The original request "Include the functionality of importScript into
> mediaWiki.loader.load" is in my opinion a WONTFIX. Until a proper solution
> exists, please use importScript() (or if you need a callback, use
> jQuery.getScript(url, callback).
> 
> The underlying need however is not a wontfix, but a valid need. Instead of
> addressing that by adding support for direct loading of a wiki page to
> mw.loader.load is bug 34958 (creation of ResourceLoader modules on a user
> level)


See bug 34958 instead.

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


Navigation
Links