soledad penadés

repeat 4[fd 100 rt 90]

My first ajax-y attempts were done with prototype. It all seemed so natural and seamless: prototype came with rails and there were those nice javascript helpers like link_to_remote which generated the javascript code for calling prototype functions. Until you looked at the code! (and the weight of it). I'm not talking about the ruby code but the output HTML, which is heavy and plagued with very obtrusive javascript.

Since I'm a concerned person, I decided to ditch Prototype and its Scriptaculousy effects and use jQuery instead. And I thought: since jQuery is so cool, I'm pretty sure that somebody will have done a replacement for the default javascript helpers (based in Prototype). But I was wrong. Not completely wrong, but quite a bit.

There's some work done in this area; a guy whose page is titled Katz got your tongue? is working hard in getting a jQuery On Rails plug-in up and running. Incidentally it seems he's also a jQuery developer so that's very good too. But since the plug-in is not finished yet, I kept looking for less obstrusive alternatives. I remembered about the unobtrusive plug-in that Luke Redpath & Dan Webb talked about in a LRUG meeting, UJS, and although it looked really cool, I realized am not sure if that's what I want.

Right now, it looks easier to simply write the HTML and add some JS (not in the html itself) which behaviourizes the elements, using jQuery for this, rather than using UJS's apply_behaviour. Specially because at the end, UJS is still using Prototype, and it is very slow compared with jQuery.

In my tests, which are so unscientific that I don't have any result indicator more than my own subjective speed perception, effects made with Prototype+Scriptaculous ended with what I call the 1fps syndrome: the screen gets updated only 1 time per second, so you forget about concepts like smoothness, transitions, easing and all that quite quickly. Way more quickly than it takes the effect to execute, actually; when it finishes you have almost forgotten what you wanted to do. Meanwhile, jQuery kept always a decent framerate and didn't feel like overloading the processor. And this happens in all types of machines.

So I think I'm going for jQuery, doing things in the style of this guy over here, and will keep an eye in jQuery for Rails development.

According to this document at Mozilla Developer Center, Javascript 1.5 has been implemented in a browser since at least the first releases of Mozilla as open source browser, which means, in other words, since around 1998. Let's assume it was 2002 which is marked as the release of the 1.0 version.

And I was doing some interface programming lately and I needed to check if an element was in an array. Went to Gecko's documentation (that's the one I normally use, since it's less overbloated with crappy ads) and checked that Array objects had an indexOf function. Cool! I used that function on my code. Then once I finished with all the development, went to The Horror (i.e. Internet Explorer) and tested it.

Surprise! It was broken! What had I done? (You know the debugger for Internet Explorer is not specially helpful)

I suspected of the indexOf function, and recalled vague memories about doing a custom search function in the past for looking into arrays and not having to write a for(i=0; i<ar.length;i++) thing each time…

Mmmm… did a alert('Array.indexO') in ie and what did I get?: undefined

So they have been spent five years for releasing ie7 and still they didn't implement Array.indexOf!

No worries, though. Javascript is flexible! Look, IE, I don't care if you choke on the mere seeing of indexOf, you're going to run it whether you like it or not!

	if(!Array.indexOf){
	    Array.prototype.indexOf = function(obj){
	        for(var i=0; i<this.length; i++){
	            if(this[i]==obj){
	                return i;
	            }
	        }
	        return -1;
	    }
	}

and voila! my script wasn't broken anymore!

Ok, this is not serious, it contains high quantities of fine web developer fun. Please do not read it if you don't feel that geekly ironic…

I was trying to update my e-mail address at lastminute when I was treated to a series of consecutive WTF, each one being even more astounding than the previous one. And I wanted to share it with you so we all can enjoy this product of engineering.

As web developer, I expected to find an option for logging in first, and then changing my account details. But not, you choose first "Your account" and then you click on "Manage your personal and site details". Yeah it looks good (but weird). Anyway, when I click on the second link I get to a page like this:

Please note that I had to manually add the input box for current email address, since it wasn't added by the system. Seems they like us to practise the trendy Do-It-Yourself hobby.

The problem is that I can't paint input boxes in the browser, so when I entered my new email addresses, the system gave me this error:

I must confess that I was kind of waiting for this error to appear. It's like, you know, when you want to delete something in Windows and it asks you each time "Are you sure you want to send the file to the recycle bin?".

So I had the hope that the missing input field would appear now, magicly! because they would fix their error of not showing my input field from the beginning. But there's more fun to come!

I tried going back to the first screen and chose the option for checking my Purchase History, as I thought: that one is asking me for my password, so maybe once I check my Purchase History, it will show me an input field because I will be logged in. So I entered my email and password, and…
Tadaaaaaaa!

The best error message I've seen in a long time!

Unsupported keysize or algorithm parameters.

Come in, I'm sure you are counting the minutes till you can use it in your own application. You're secretly desiring to find a good place to trigger this error. Maybe when there are not enough products in stock? When an operation has completed successfully? Just about completing transfers in a banking application? That one looks like a cool new home for this error. Let's read it again:

Unsupported keysize or algorithm parameters.

It's so delicious, so obscure for us the illiterate users, and I'm sure the IT guys know very well what it means. When a user fills in a support ticket with the subject "I'm getting an unsupported keysize or algorithm parameters", they have good laughs. HAH! he's getting The Error! He's fucked! HA! HAHA! =))

But let's not get distracted with this tremendous load of fun. I forgot to tell that the pink circle with an exclamation mark actually is BLINKING. So that it actually shows like this:

Unsupported keysize or algorithm parameters

That looks quite cool but I think it would have improved a lot if everything had been blinking.
So as I saw that there was no way of changing my email from there I just thought: let's go back to the form with the missing input field and let's find out what's going on there.

There's an embedded javascript in the very page, being triggered when the form is submitted. Also, as I guessed, the input for my current email address it's in the form, but it is hidden, as the web developer toolbar's "Forms - Display form details" function (and a view to the page's source) will quickly demonstrate:

There are also a couple of "textfeild" which look very funny too. Extremely funny, indeed!

But again, let's not get distracted with the fun! We can directly input the value of the current login (i.e. my current email address), now that Firefox shows us the hidden fields.

That's cool! With filling this and my new desired e-mail address, I just get to this confirmation page:

So it looks like I changed it! Maybe not, because I didn't fill in all the fields. When I get the next e-mail with stupid travel offers, I'll tell you.
Actually this serves for another purpose, apart of giving tons of fun, which is to remind everybody that javascript validations are baaaad. As you see, they are easy to forge and break even more easily.

And now let's find a place for The Error!!

There's little things that bore me more than having to write inline javascript for little tasks like closing a window. So I thought of a way of having javascript do it for me!

Basicly this is the idea: I assign a certain class (CloseWindow) to the items that I want to act as Window Closers, and when the page is loaded, a little script finds out the document tags with that class and assigns them a function for their onclick event.

As I wasn't feeling like writing a function for traversing the whole DOM tree for searching elements class names, I also used a function, getElementsByClass by Dustin Diaz, to discover the elements with a certain class name. So yes, the rest was pretty easy :P

Now to some code:

function getElementsByClass(searchClass,node,tag) {
// Taken from http://www.dustindiaz.com/top-ten-javascript/
var classElements = new Array();
if ( node == null )
node = document;
if ( tag == null )
tag = '*';
var els = node.getElementsByTagName(tag);
var elsLen = els.length;
var pattern = new RegExp("(^|\s)"+searchClass+"(\s|$)");
for (i = 0, j = 0; i < elsLen; i++) {
if ( pattern.test(els[i].className) ) {
classElements[j] = els[i];
j++;
}
}
return classElements;
}

The code for intercepting the onload event of the window:

window.onload = function() {
// Replace all elements with 'CloseWindow' class onclick handler with
a call to the windowclose function
var closeWindowElements = getElementsByClass("CloseWindow");
var i;
for(i=0; i < closeWindowElements.length; i++ ) {
closeWindowElements[i].onclick = function() {
window.close();
}
}
}

Finally, the code for a Window Closer element:

< button type="button" class="CloseWindow">Close< / button>

Of course all of this can be improved, you can use a custom events handler instead of just overwriting the current events of those elements, or even the current onload event of the window object, but for the purposes of demonstrating this possibility this serves completely well.

And also this is not the perfect way of having close buttons (as in the case of a site which needed to be open to the public and being completely accessible, no close buttons should be assumed as we can't assume that the users' devices are windows capable), but for sure it's going to be better than having embedded javascript in the middle of your code.

Oh, and the getElementsByClass function could be improved for allowing to discover elements with more than one class (see below), like for example class="post veryimportant". Currently the script just can detect literal values, and if you search for elements with class="veryimportant" or class="post" it will find nothing.

*Because you know that you can assign more than one class to an element, don't you? Well, now you know!

I was just doing a little javascript, and i needed to output a pair of values with the classical window.alert. It worked ok in firefox, then I went to iexplorer and suddenly I heard that stupid sound when an alert window opens ("blink!"), that I had almost forgotten.

Seriously, do we need that sound? Everybody was complaining about the ridiculous improvements in css support in the upcoming IE7, but I think this is very important too. It is something which points at you: "YOU HAVE MADE AN ERROR! YOU STUPID USER!", making you feel ashamed (specially if there's someone around looking at you).

And yes I know you can deactivate the sounds in windows, don't come with that answer…

*giggles*

NOTE: would be nice if you appreciate the subtle irony before populating my comments with IE-is-not-that-bad kind of comments…