Last night I made a change to how ResourceLoader's debug mode works; one based on an idea which has been hoped for since the inception of the project but had not yet been fleshed out well enough to implement. It's for the most part an implementation detail, but it changes something I posted on this list so I wanted to provide an update.
On 9/29/10 3:27 PM, Trevor Parscal wrote:
When a request is made for one or more modules, each resource is packaged together and sent back to the client as a response. The way in which these requests and responses are performed depends on whether debug is on or off.
This now happens, no matter what the debug mode is.
When debug mode is off:
* Modules are requested in batches * Resources are combined into modules * Modules are combined into a response * The response is minified
Production mode (debug=true) is unchanged.
When debug mode is on:
* Modules are requested individually * Resources are combined into modules
Development mode (debug=true) has changed a bit. Modules are still batched, but now the code from ResourceLoaderFileModule-based modules is sent in the form of a document.write( '<script src="path/to/raw/file.js"></script>' ) instead of being embedded directly. This means that we can take advantage of the loading system, but also have direct file includes, making 100% line/character matching with the original source files (because you ARE loading the original source files).
Thanks to Michael Dale for helping me sort out the best way to implement this.
I think it's debatable whether debug=true mode goes far enough, since it still combines resources into modules, and I am open to contributions that can make debug=true mode even more debugging friendly by delivering the resources to the client as unchanged as possible. I also think it's debatable if debug=false mode goes far enough, since things like Google Closure Compiler have been proven to even further reduce the size of JavaScript resources, so I am also open to contributions which can make debug=false even more production friendly by improving front-end performance.
This is still my position - in r75137 I took development mode (debug=true) a step further by making it easier to understand where the the client has received came from on the server, and supporting tools that can connect a browser to an IDE by thus preserving line-numbers and character-offsets. I am considering ways to continue to make improvements to how easy we can make development mode for developers - ideas are welcome, commits and patches are appreciated.
I also still feel strongly that we should not hold back on making production mode (debug=false) as optimized as possible. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75137
If you are a developer, working on your localhost, you probably want to code with...
$wgResourceLoaderDebug = true;
.. and then test that things work in debug=false mode before committing your code. This will result in more requests but less processing, which will be much faster when developing on localhost.
More information about how ResourceLoader will affect your development process, and how to take control of it has been added to MediaWiki.org:
http://www.mediawiki.org/wiki/ResourceLoader/Documentation/Developing_with_R...
I would also like to just take a second to thank everyone, staff and volunteers alike, for all of the patience and support you have all shown Roan and I while we have been developing ResourceLoader. We really believe that this is a big step forward for MediaWiki towards making it a modern wiki platform, and look forward to seeing it in action on high and low traffic wikis alike.
If you are wondering what's next for ResourceLoader, take a peek at the task list on MediaWiki.org:
http://www.mediawiki.org/wiki/ResourceLoader/Status#Task_List
- Trevor