On Mar 20, 2012, at 11:15 AM, Dmitriy Sintsov wrote:
* Krinkle <krinklemail(a)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