Just a quick heads-up for those who’ve been complaining about the MooTools version of the multiple-file uploader not working with MooTools 1.2 — it’s now been updated. The widget required three small modifications due to changes to MooTools’ syntax.
Get the modified code here (old 1.1x-compatible version also included).
…yes, I know, I go on about Firebug a bit.
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.
Some time back, while experimenting with MooTools, I found myself with the requirement to be able to call a function whenever a particular method on a given class was called. In effect, I needed to treat the class’s method as an event and fire a particular function when the method was called.
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.
I spend most of my time developing server-side code and testing in Firefox so I don’t usually worry too much about other browsers. But when — as now — I find myself writing JavaScript and CSS, and struggling with all the cross-browser horror that comes with it, I need all the help I can get.
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.
Another one of those really obscure ones…
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);
});
}
}
},