ResourceLoader/Version 2 Design Specification


 * Initial work to sketch out this document are on the RL2 Etherpad
 * "Pseudocode Architecture Session" : http://etherpad.wikimedia.org/RL2-GadgetAbstract

= Gadget Manager = Tracking: bug 29398

Use-cases
By having a visual manager gadget managers will no longer have to learn yet another syntax to register gadgets and/or modify their properties. The Special-page will be able to log events which will enable users to easily see who changed what. They will be able to get that informaiton chronologically for all gadgets (What has been done in the last few days?), or for one particular gadget (What happened to Gadget Foo ?). This is handled through  and. Over the last year more and more options have been added to gadgets and resource loader modules. There's about a dozen module properties and half a dozen Gadget properties (gadget title, description, and settings (required rights, enabled by default), module scripts, styles, dependencies, messages, and more..). Having them in a nicely designed form with responsive javascript interactions and suggestions will make it easier to understand and extendable without complicating the "Gadget syntax" (which will cease to exist). Through this interface, the process of 'Adding' (or 'Creating') a gadget will be as simple as a click. Aside from writing one from scratch another goal of the Gadget Manager is to enable easy exporting and importing of Gadget properties from one wiki to another. This is done through the JSON format which can be read and written natively in most browsers (and for other browsers an emulation module is present in SVN). Note however that duplicating is no longer intended to happen as much within the Wikimedia farm due to the new Global gadgets feature, which no longer needs the local wikis to "copy" or "redirect" a gadget from a central place. If time and tech allows we might even implement an InstantCommons-like feature in MediaWiki which allows third party wikis to easily get useful gadgets, that are actively developed within Wikimedia, onto their own wikis.
 * Usability
 * Tracking
 * Extendable
 * Sharing

Storage of Gadget properties
The properties of each gadget will be stored in a new MediaWiki database table,. mysql> DESCRIBE mw_gadgets; +--+-+--+-+-+---+ +--+-+--+-+-+---+ +--+-+--+-+-+---+ There may be an additional column insert before  (" ") in which case gd_name wouldn't be the   but a. A numerical id could be handy in some places. This is to be discussed.
 * Field       | Type                | Null | Key | Default | Extra |
 * gd_name     | varbinary(255)      | NO   | PRI | NULL    |       |
 * gd_blob     | mediumblob          | NO   |     | NULL    |       |
 * gd_global   | tinyint(1) unsigned | NO   |     | 0       |       |
 * gd_deleted  | tinyint(1) unsigned | NO   |     | 0       |       |

There will be an API module to read from and write to this table. This will primarily be used in the javascript enhanced Gadget Manager (Saving on-demand to the API without a page refresh).

Gadget resources
The resources will stay where they are: As pages with revisions in the wiki database. The difference intended to be made as part of the ResourceLoader 2 project is moving these out of the prefixed "Gadget-" scope in the MediaWiki:-namespace (which is intended for messages, not actual wiki content (let alone executable resources). Instead move them to a new Gadget:-namespace only editable by users with the  right.

Messages
The title of the gadget and the description associated with will stay in the MediaWiki:-namespace. The main reason for this is, is to enable easy localization and centralization of the description.

Aside from the title (eg. ) and the description (eg. ) a gadget can have a number of custom made messages. These are handled by the existing system present in MediaWiki which is suited for this already and are loaded through the messages framework in ResourceLoader (associated at module registration and passed to the browser through ).

Designs
= Global gadgets =

Implementation proposal
= Top load queue =

Use-cases
Modules that style the output from the server directly (ie. not content generated by JavaScript) should load from the top instead of the bottom. This to avoid a "flash of unstyled content". By loading it from the top the styling will be known to the browser when the content is parsed, thuss no "flash of unstyled content" will appear. Modules that insert, modify or remove elements on the page need to be loaded from the top in a "document ready" wrapper. Otherwise the user could see a short "jump" in the page where something is added, removed or otherwise changed. By loading these from the top they will be able to queue themselfs to start "changing" the content as soon as it's loaded.
 * Content styling
 * Content modification

Implementation proposal
The top load queue is actually quite easy to implement. What we need:
 * An additional property in the module registry for "position" which can be set to "bottom" (default) or "top".
 * The OutputPage class needs to be adapted to know about "positions" and add a loader command in the top if there are any modules with the "top" position, and in the bottom the load-everything part needs to be changed to filter only the modules with their position set to "bottom".

= Noscript stylesheets =