It’s been a few weeks now since I made the decision and I’m starting to become more comfortable with jQuery’s quite different approach. I’ve also begun working on some of the more complicated aspects of the new CMS, including adopting jQuery UI to provide the interface widgets. One requirement of the system is to have a dialog where search results can be dragged and dropped onto a sortable list.

At first I looked at using two sortable lists and the built-in ‘connectWith’ option, which enables you to link two or more sortable lists together. But then I realised that I didn’t really want the search results to be a sortable list. In fact, what I wanted was a static list whose items could be dragged and placed in the sortable list.

I tried a few experiments, and when those failed I decided to try looking at the code itself to see if I could hack together a solution without too much extra effort. While browsing the ui.draggables code, I stumbled across the intriguingly-named ‘connectToSortable’ option. I was surprised to find it because there’s (currently) no mention of it in the documentation, and indeed it’s very hard to find any reference to it at all beyond the code itself (the only useful link I could find was this one, but it rather over-complicates the issue).

It’s very simple to use: as with connectWith, just specify which sortable(s) you want to connect to with the connectToSortable property:

$('#myDraggable › li').draggable({helper:'clone',connectToSortable:'#mySortable'});

Full example code here.

The code for the example works just fine, but I found when using it in my own project, for some reason it was necessary to add a $(‘mySortable’).sortable(‘refresh’) call after defining the two lists, or the first drop operation would always fail.

By the way, when fiddling around with JavaScript experiments I find JSBin very useful — you can load up any of several JS libraries (jQuery, MooTools, dojo, prototype, YUI, script.aculo.us) and create both JavaScript and HTML to test in a ‘live’ environment. Very handy.

I’m creating forms dynamically using JavaScript. This has led to a number of problems with IE6:

Dynamic checkboxes/radio buttons and the ‘checked’ attribute

When creating a field, I wanted to be able to apply a ‘default’ value — for example, a checkbox element might be ticked by default. This was all going smoothly until (guess what?) I tested it on IE6: the checked attribute was set, and returned ‘true’ when tested, but the box did not appear to be checked when it appeared in the form.

The answer, as I discovered thanks to this forum post, was to use the ‘defaultChecked’ attribute instead (I set both, just in case). It seems to work across browsers, which is nice. Oh, and this applies to radio buttons as well as checkboxes.

Creating radio buttons

While we’re on the subject of radio buttons, I also found that IE6 doesn’t like radio buttons created using document.createElement() (i.e. as a DOM object). It’ll render them OK, but they’re unclickable. The answer is to create them by injecting HTML into an element with [element].innerHTML:

var obj = document.createElement( ’span’ );
obj.innerHTML = ‘<input type=”radio” name=”somefield” value=1>1′;

…and so forth. Ugly.

Assigning values to multiple select elements

This was a really fiddly one, and seems to happen under only very particular circumstances. Anyway…

If you create a select element and set the ‘multiple’ attribute, IE6 can sometimes have trouble assigning values to it if you do it immediately after it’s created. Note the word ’sometimes’: I haven’t been able to create a simple enough test case to isolate the exact circumstances that are required. And it’s only a problem if you’re setting more than one value.

Anyway, the (horrible) fix is to delay setting the values using setTimeout(). The delay doesn’t matter (1 millisecond will do), but it does work.

I hope these notes help some other unfortunate soul out there avoid wasting the number of hours and brain cells that I just have!

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

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.

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’.

It’s about 18 months since I released my simple script for creating a prettier way to include multiple file elements on a page. In that time it has remained by far the most popular page on this site, in spite of the fact that I haven’t updated it since and have long since given up trying to keep up with the comments it still generates.

Anyway as a way of getting to know Mootools, I decided to rewrite it to take advantage of the framework. I took the opportunity to clean up the code a bit and make it easier to style the output.

You can find a zip file for MooTools version 1.2 here (included is another zip file with the old, MooTools v1.1 compatible code) with the full annotated source code, also a compressed version (it weighs in at just 2.5K), some simple CSS, an example HTML file and a readme (which is basically identical to the extended comments at the top of the source code).

There’s a simple example page here. As ever, comments and bug reports welcome.