On Mar 20, 2012, at 11:15 AM, Dmitriy Sintsov wrote:
- Krinkle krinklemail@gmail.com [Mon, 19 Mar 2012 14:32:51 +0100]:
Converted all of for..in into $.each(). The most funny thing is that $.each() did not work correctly with sparse arrays [], walking with "undefs" between real elements. While for..in used to work fine (FF,Chrome,IE8,IE9). So I had to convert sparse arrays into sparse objects {}, just as you recommended. This way $.each() works, however it also creates new context (different "this") so I've had to use var myself = this more often than it used to be.
Few points: * The easiest way to understand it is to consider "sparse arrays" to not exist in javascript. It doesn't throw an exception if you try it, but it's not supposed to be posisble, so don't. * Sparse objects don't exist in any language afaik. What you created is just a regular plain object. Although you may assign values to a numerical key, it really is a string, so be careful that you don't assume they are a number: <code> var a = {}; a[4] = 'foo'; $.each(function (key, val) { // typeof key === "string", key === "4" for ( var key in a ) {}; // // typeof key === "string", key === "4" </code> * As I said before I think there is no point in using $.each() in this case. It is nice if you need a context but as you already found out, more often than not it's actually a burden to have to deal with it if you just want a loop inside an existing context. I would've kept the for-in loop you originally had which was just fine, only change the array into an object.
The most pailful part was to pass control to the main module after edit module was abruptly terminated (without any warnings in Chrome console). I managed to call the main module method directly from edit module. Not a very nice thing, but at least it works. Who would know that such potentially easy thing as refactoring one js class into two ResourceLoader modules can be that much painful. I used to dynamically load jQuery for custom MediaWiki 1.15 installation via LABjs and don't remember such problems back then.
I'd have to look further into the actual code to know what you mean here, but there isn't really such thing as "refactorign a JS class into a ResourceLoader module". For one, javascript doesn't have classes, but that's just word choise. Secondly, ResourceLoader "just" loads javascript. You don't have to refactor anything. There are a few things that it enforces (such as execution of the javascript file in a local context), but other than that you don't have to change anything "for ResourceLoader".
There are a lot of conventions and best practices often associated with "porting to ResourceLoader" but that's more along the lines of "now that we're working on this, lets get rid of crappy code and make it nice", not anything ResourceLoader actually requires.
I'm curious what kind of problems you are referring to here? The kind of problems you didn't have when you loaded jQuery in MediaWiki 1.15
-- Krinkle