Well, it’s almost Christmas! With the holidays getting closer, I went through some dusty files and stumbled upon an oldie but goodie: a 2-dimensional fish eye element (technically it’s also quasi-3d, but whatever). It uses Prototype and Scriptaculous and is available on Github here.

It’s something I actually needed to write for work over a year and a half ago – can you imagine?

Merry Christmas to all from everyone at Nodeta!

Here’s the thing with chrismassy icons!

The free Christmas icons can be found from here.

We’ve been feeling sorry because we didn’t pay much attention to rails-doc IE compatibility. Today I had a look at the server statistics, and it seems that even the iPhone browser is more popular than Internet Explorer. :) Good to see that Rails developers have such a good taste.

Anyways, today is the Firefox 3.0 download day:

Go and get it! The super-fast JavaScript interpreter is going to enable lots of new possibilities in web UIs. I’m really looking forward to see stuff like SproutCore used in different kinds of applications.

PS. The upcoming Rails-doc.org JavaScript search is already going to benefit from the upgrade. ;)

I noticed something really strange in the Prototype API today after a fellow developer came smirking to ask me why an export action seemed to quickly success after he had dropped the whole server. I tried to reproduce the situation and surely enough, the onSuccess callback ran when there effectively was no response. I immediately perused the Prototype API documentation and to my amazement read this description for the onSuccess callback:

Invoked when a request completes and its status code is undefined or belongs in the 2xy family. This is skipped if a code-specific callback is defined, and happens before

onComplete

.

Did you notice that? “Invoked when a request completes and its status code is undefined…” What on earth!? After some googling, I found out that this is no new discovery and that there’s more to this problem than you’d think.

Different browsers handle the situation differently, and so, what eventually ends up in the status field of the response object, varies greatly depending on the browser and the protocol. Since there is no standard XMLHTTPRequest, there is no standard behavior for a browser regarding what should be passed to the JavaScript response object. In the olden golden days of standard HTTP requests there of course is no problem because there just is no response.

Apparently, when a network problem occurs and no actual response is received, Firefox and Opera (most versions) pass an undefined status with status code 0, IE passes its own proprietary status codes in the 1000-range and Webkit/Safari, in addition to the occasional status code of -1004 (!), also passes a status code of zero. Other problems are brought on by the use of file protocol.

There has been a few suggested patches (1) (2) (3) (4), and the status quo will hopefully change soon.

In the meantime, you can solve the problem in at least these ways:

1. Use the on0 callback (that’s “on”-zero) to separately handle the cases when the browser passes a status code of zero to the AJAX Response object. The fired on0 will block the onSuccess from firing.
2. Forget all the different completion-related onXXXX callbacks and simply only use the onComplete and manually check if the status code pleases you – something along the lines of this:

   new Ajax.Request("/path", {
     onComplete: function(response) {
       if (response.status==200)
         alert('Very successful!');
       else
         alert('Far less successful');
     }
   });