Get the modified code here (old 1.1x-compatible version also included).

OK, a lot.

But good as it is it can still be improved, as this list of Firebug extensions proves. There were several on the list that I hadn’t heard of before and have already installed.

So I wrote a very small addition to the Mootools’ own Class code, which allowed this. The new method, Class.bindFunctionToMethod(), allows you either to intercept the method call before or after it’s fired. If fired before you can change the arguments being passed in, while if fired after then you can alter the return value.

Of course you need to be careful how you use it: by ‘piggy-backing’ on method calls like this (especially if you alter the arguments or return value) you’re potentially altering the script’s behaviour in a way that’s not necessarily evident by looking at the classes themselves.

You can download the code here: it’s heavily commented, so it should be fairly obvious how to use it. It works just fine with MooTools version 1.1+ and 1.2.

Opera has made great strides recently with Dragonfly, its own answer to Firebug (the current yardstick by which all other developer tools are measured), and while not quite as good it’s improving all the time. Safari is lagging well behind with its Web Inspector, which promised much when it was relaunched last year but thus far has failed to deliver.

When it comes to Internet Explorer, the situation isn’t as awful as one might expect. Until recently I’d been using a combination of Developer Toolbar and Script Debugger but today I stumbled upon DebugBar, an IE extension which comes a lot closer to Firebug’s functionality, especially when it comes to inspecting CSS rules and so on. Its handling of JavaScript errors doesn’t improve much on IE’s own abilities — it still won’t tell you which file an error has occurred in, for example — and it seems to have trouble inspecting some script-created elements. Still, worth a look.

UPDATE: while we’re on the subject of developing in IE, I should mention CachePal, a shortcut button that clears IE’s cache. Handy when you’re developing (say) JavaScript, because IE has a tendency to hang onto old JavaScript files even after a SHIFT+Reload.

So as previously mentioned, I’m looking at using MochaUI in a CMS project I’m working on. Everything was going swimmingly, except that for some reason it was having rendering problems with (you guessed it) Internet Explorer. At first I thought that it must be a CSS problem, but lengthy experimentation suggested that this was not the case.

With the help of a colleague I eventually narrowed the problem down to MochaUI’s use of Google’s ExplorerCanvas library (excanvas), which provides a wrapper for IE that simulates canvas support. One wrinkle in our use of MochaUI is that the scripts are being loaded dynamically when needed (using MooTools‘ Asset methods). It turns out that excanvas expects to be loaded at page load time, so attaches its initalisation function to the page’s onreadystatechange event — waiting for the page to be ‘complete’ before initialising. Of course, this didn’t apply in our case since the page had already finished loading when the script was included. So it was never initialised.

All that was required to fix the problem was a slight change to the library’s init method (bear in mind, I downloaded the latest version (0002 — dated May 4 2007):

init: function (opt_doc) {
var doc = opt_doc || document;
if (/MSIE/.test(navigator.userAgent) && !window.opera) {
var self = this;
if(doc.readyState == "complete"){
self.init_(doc);
} else{
doc.attachEvent("onreadystatechange", function () {
self.init_(doc);
});
}
}
},

I posted a bug report yesterday and as far as I can tell it’s slated to be looked at for the next release (1.3), but while pondering the problem overnight I came up with an idea and with some help from this blog post I was able to create an interim fix. Because it uses XMLHTTPRequest it can’t load CSS from a third-party domain, but it works for what I need and it’s better than nothing until the official fix is forthcoming.

I’ve put the code into this file (right-click, save as…) which you simply load after MooTools itself (it replaces the existing Asset.css definition with a new one).

My first stop would have been the official MooTools forum, but in their wisdom the project’s leaders have decided to remove them completely. The oft-mooted ‘MooForge’ has never materialised but after exploring a variety of blind alleys I came across MooScripts, an unofficial but quite comprehensive collection of MooTools add-on scripts.

From there I was led to the Mocha UI project, which is a fairly lightweight implementation of dialog boxes for MooTools 1.2. It’s feature list is impressive and it’s quick too (compared to others I tried). Like Mootools it also uses the very permissive MIT licence, which basically says ‘use it how you like, at your own risk’.

However I do have one caveat to add. I use the portable version (running from a USB key) and found, after some weeks of use, that it was becoming increasingly sluggish. I put up with it for a while but was getting quite frustrated when, one day, I got an error when shutting down the browser. I don’t remember the specifics, but it mentioned a file in my profile directory called urlclassifier3.sqlite.

Out of curiosity I looked at the file and found that it was over well over 70MB in size. This made me even more curious, so I did some searching and found various references to it and its potentially detrimental effect on Firefox’s performance. So I renamed it, restarted Firefox and — presto! — the browser was back to its former, sprightly self.

Some further digging revealed that this is a cache file for data about phishing and malware sites, and can be disabled by unchecking the “Tell me if the site I’m visiting is a suspected attack site” and “Tell me if the site I’m visiting is a suspected forgery” options in Tools > Options > Security. Of course, you do so at your own risk — you could alternatively leave theese options enabled and just delete the file once in a while, when it gets really big and FF starts to slow down.

OK, two caveats: I’m definitely in the ‘I hate the AwesomeBar‘ camp — I’m a
creature of habit and the old-style auto-complete worked just fine for
me. Bah.

I’m still kind of disappointed that I didn’t follow through with it but recently I found something that ticks most of the boxes that I was interested in, and plenty more besides. Going by the slightly ungainly name of mon.itor.us, you get plenty of neat options for keeping track of your site’s responsiveness, several types of notification (including SMS if you need it) - and they even send you a weekly summary report. The basic service, which will probably be fine for most people, is ad-supported and free.

Today I came across (something like) this little snippet:

if( ! $obj = new myObject( $id ) )
{
  throw new Exception( 'Not a valid object' );
}

At first glance we might assume that the constructor attempts to populate the new object with some data loaded from (say) a database, but if no data matching the supplied ID is available, then the constructor returns false to indicate this. All very reasonable, right?

Except that it’s not possible to return false, or indeed any value, from a constructor because the ‘return value’ of the constructor is the object itself. Which means that the above snippet is redundant, because the expression will always evaluate to true.

It would’ve made more sense to throw an exception within the method that loads the data — and in fact this is exactly what happens, which makes the quoted code doubly redundant and even more inexplicable.

I don’t think I’m the one who’s responsible for this particular brain fart but it’s OK because the only other likely candidate left the company last year so I happily can blame it on him…