MooTools: converting from 1.1x to 1.2
Published July 28th, 2008More of a reminder for myself than anything: here’s a simple changelog that could be of use when updating scripts to MooTools 1.2.
More of a reminder for myself than anything: here’s a simple changelog that could be of use when updating scripts to MooTools 1.2.
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.