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_…
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
What about setting a cookie to go into a debug mode? I thought you liked
the idea?
Regards,
Nux.