OO JavaScript, such as it is

I teach Ajax on a somewhat regular basis, so it’s rather embarrassing to admit I never really understood JavaScript closures. Of course, I thought I did. Now that I’m reading Dave Crane’s Ajax in Practice book, though, I see now what I was missing before.

He has wonderful examples in that book. I love it when he gives me examples that I can just type into a Firebug console in my browser and show everybody.

For example, I think one of the early samples is like:


function getName() {  return this.name; }

var o = new Object();
o.name = "Object";
o.getMyName = getName;

window.name = "Window";

getName();  // returns "Window"
o.getMyName();  // returns "Object"

In other words, the this variable points to the current window if you don’t say anything different, or to the current object if the method is a property of the object.

Then there’s the beauty of the call() function, which allows you to invoke a function in a particular context.


getName.call(o);  // returns "Object"

Sweet. Also, I get it now that there are no real classes in JavaScript. Instead, you have functions that act as constructors only because they have properties in them that get assigned. When you use the word new with one of these functions, you’re essentially creating a new Object and adding properties to it.


function MyClass() {
this.name = name;
}

MyClass.prototype.getName = function() { return this.name; }

var m = new MyClass("Fred");
m.getName();  // returns "Fred"
m.getName.call(window);  // returns "Window"

And the really weird part is that MyClass is just a function, so I could just call it directly without the word new. Also, the MyClass function has a function inside it, which returns another property of whatever the context object is.

Bizarre. As a developer who was raised on Java, it’s a whole different world.

I solemnly promise, however, that now that I’m really becoming a Groovy developer, I will not become one of literalists who claims that Groovy closures aren’t REAL closures. 🙂

Dave Crane is a genius

The other day I picked up a copy of Ajax in Practice, by Dave Crane and several others.

I don’t know why I waited this long.  His Ajax in Action is one of my all-time favorite technical books.  I also have a copy of Prototype & Scriptaculous in Action, though I’ve only read a few sections of it.  I think the fact I haven’t made as much progress as I would have liked in P&SiA is what made me hesitate about Ajax in Practice.

I’m only a few chapters into it now, but let me just say this:  If you ever see a technical book written by Dave Crane, just buy it.  It doesn’t really matter whether you care about the topic or not.  The book’s first few chapters are packed with more wisdom and great discussions than ten other books on my bookshelf.  He also has a free, easy writing style that makes reading his text a joy.  And believe me, it ain’t easy to make JavaScript a joy.

Dave Crane rocks.  If I ever manage to write a technical book myself, I only hope to come anywhere near his level of excellence.

(Of course, Scott Davis isn’t bad, either. :))

Ajax in Amsterdam

You know what I hate?  When I feel my phone vibrating on my hip and I’m not wearing my phone.

This is my first time in Amsterdam.  The training site is an IBM center, but I think this is just a room rental.  I’m a sub to a sub to a sub again, so it’s a bit confusing.  It’s also rather surprising that my client’s client felt that it was worth the travel costs to hold a class for only three people.  Works for me, though.

The Ajax materials I’m using this time are very different from the one’s I’ve used before and they’re pretty raw.  Lots of set-up and lab corrections to do, but I think I have most of them worked out now.  It’s very interesting that these materials are strongly focused on Ajax tool kits like Prototype, Dojo, and Rico.  That’s no doubt the future of Ajax.  From a spectator sport point of view, I’ll be watching to see which toolkits win the mindshare wars.

Prototype is definitely going to win, partly because it’s cool ($(), $F(), and all that) and partly because it’s the basis of so many others.  I’m not sure whether Dojo and Rico are going to win out over Scriptaculous, though.  We’ll see.

Ajax (another try)

Since my previous post vanished into the ether, I'll try to regenerate it. Grr again.

I spent this week developing Ajax materials for a client. They asked me to put together a half-day of materials, including PowerPoint slides and a lab. This request had a few elements in its favor:

  1. I really like this client and want to make them happy.
  2. I like Ajax, too, and wanted to dig into it a bit more. Besides, on of my favorite technical books at the moment is Ajax in Action by Dave Crane (Manning), though I did spend a lot of time with Foundations of Ajax (Apress).
  3. The request seemed like it was going to be easy and quick. (Yeah, right.)
  4. They were going to pay me.

All good things, you must admit. At any rate, I said yes, cranked up the old MyEclipse editor, and went to town.

Unfortunately, I hadn't yet made my 10 Canonical Errors in Ajax. 10 Canonical Errors you ask? I need to make a separate post about that, but in short, my feeling is that in any new technology there are at least 10 canonical errors you have to make before you become productive. Each one will likely cost you hours of debugging time. The difficulty is that there's no way to know what those errors are before you make them. It's just part of the learning process.

Why 10? No reason. It's just a nice, round number and it's also probably a significant underestimate.

When building my Ajax demos and labs for these materials, here are a few of the ones I stumbled across.

  • XHTML is evil in at least one respect. When an element is defined in the spec to be not empty (i.e., the content model is anything other than EMPTY in the DTD), you have to write it as separate start and end tags rather than in its minimized form. Otherwise the browsers don't understand it. Yikes.

That means use <script src="myscript.js"></script> rather than <script src="myscript.js" />. The same goes for <div id="message"></div> instead of <div id="message" />. This is actually in the spec, but it took a while for me to find. Check out section C.3 here.

  • The onreadystatechange property of the XMLHttpRequest object needs to be assigned to a function pointer, not a function.

Duh, and duh. Use xhr.onreadystatechange = handler instead of xhr.onreadystatechange = handler(). The former is a pointer to a function defined in the same file. The latter is a definition of an empty function.

  • The text value of an element in the DOM is in its first child. Yeah, I've known that for years, but that didn't stop me from making that error again.
  • For an HTML form element in the DOM, you set its value using the value property. For an XML DOM element, you use the nodeValue property. Sigh.

These two I can describe together. To set a form value based on an XML node value, use

document.getElementById("name").value = doc.getElementsByName("name")[0].firstChild.nodeValue

Wow. I guess that's why we need frameworks and libraries, like scriptaculous.

In the end the materials got developed, and I used them on Saturday in my Rensselaer Developing Enterprise Applications class, too. It was an interesting experience.

Now I'm ready to go back to Hibernate materials development for Will Provost.

Ajax

I just wrote a long, thorough post on my Ajax materials development this week and it vanished when I tried to save it. Grrrrrrr.

%d bloggers like this: