User:CodeCat/lookup language

Since you asked for feedback, some nitpicks in no particular order:

• You will be better off enabling JSHint options that I recommended. Especially undef.
• You declared a dependency on LegacyScripts, but you are not using it anywhere. LegacyScripts should not be depended upon anyway. Having (new) scripts depend upon it defeats its only purpose: to make it possible to be disabled.
• The callback function could be integrated straight into the .done() handler; well, unless you plan to call it from somewhere else.
• I tend to keep one long-lived mw.Api object instead of creating a new one every time I need to call the API. Repeatedly constructing and destroying objects costs some time.
• { 'a': 'b', } may not work in some IEs IIRC, some of which we might want to support. I do not really remember which.
• If you had the form as a raw DOM node instead of a jQuery wrapper, you could access fields like: langcode = form.inputName.value (where inputName is the name property of the field). Though see below for an alternative, I think a less fragile one.
• Some error handling would be nice. And more features, like looking up scripts, and reverse lookup (i.e. by name). And why force people to navigate to a specific page to use this? Though I realise this is just a prototype. Right?
• xte has a similar feature already, implemented a bit differently.
• I think Module:languages/JSON repacking one abstraction into another abstraction shows how the whole object-orientation business imposed upon Lua is silly.
• Placement of {. Nearly every serious JS library (and some non-serious libraries) follows (Crockford's variant of) K&R here.
• I really dislike jQuery. This may be just my taste, but I find that library too bloated, and I avoid using it unless 1) MediaWiki forces me to, or 2) I think I would end up writing a half-hearted reimplementation of something jQuery does already anyway if I avoided using it. I never use jQuery for constructing DOM — I tend to use the el function I copy everywhere (I really need to put it in a library), which is similar to newNode we have in LegacyScripts. You give it arguments describing a DOM element, and it returns a fully-formed node. The main advantage comes when you combine that with assignment-expressions:

var target = document.getElementById('mw-content-text'); // or sth
var input, button;

target.appendChild(el('form', [
	el('fieldset', [
		input = el('input', null, { type: 'text', value: 'boo' }),
		button = el('input', null, { type: 'submit', value: 'doit' }, {
			click: function (ev) {
				ev.preventDefault();
				alert(input.value.toUpperCase());				
			}
		}),
	])
], { 'action': 'javascript:void document.validity;' }));

// now input points to the input node, and button points to the button node, so callbacks work correctly

The code can be written quickly, executes quickly (almost at the speed of calling DOM methods directly; no string parsing voodoo like jQuery does), and when you get a bit used to it, is quite readable.

• Also, if you use jQuery anyway, please be consistent — either use jQuery or $.

I used the newNode function before, but then I switched to just writing out the HTML directly and didn't need it anymore, but I forgot to remove it.

I used { 'a' : ... because the key is named "class" which is a keyword. I assumed that would mean I couldn't use it.

I didn't add error handling for now because it seemed to work fine even without it. It was only a simple prototype anyway, more of a proof of concept that could be worked out and improved further. I am hoping that it could eventually become a fully fledged search engine for our data, allowing you to query and pattern match against it. I don't know if I will have the time or motivation to finish it, but even in this simple form it may be useful to some people?

And I don't really have a problem with jQuery, so I'll keep using it until I find out what reason I should have to dislike it.

You want to use jQuery — fine. Just use it sensibly. Building DOM is actually more direct — HTML has to be parsed, and parsing is costly. DOM nodes can be put into variables to be later used directly (instead of going through a jQuery wrapper object, often completely unnecessary), like I showed; putting everything into one long string and later plucking out interesting fragments complicates things. Also, carelessly manipulating the markup instead of DOM can lead to problems, like it did at MediaWiki:Gadget-FastRevert.js.

Time to start building a library, it seems. Rather easy to start: just create a gadget in MediaWiki:Gadgets-definition, and set the |skins=none option to hide it from Special:Preferences. Then use it just like you did with LegacyScripts.

About the fifth point, I was referring to the comma, not the apostrophes. (Quoting keys is actually necessary for compatibility.)

What would I use instead of the comma then?

Nothing? Comma is a separator, not a terminator.

Oh I see now. Some languages allow a comma at the end of the list, I know both Python and Lua do. Since I prefer to place the actual terminator of the list on the next line by itself, putting a comma after the last element looks a bit more consistent. It's more a matter of code style than it really being useful for anything. If not all browsers support it I won't do it for JS.