The JavaScript Identity Operators

I’ve heard rumors of this before, but didn’t quite grok it. And now that I do, it’s very cool yet very strange. To demonstrate:

js>var n = "1"
js>1==n
true
js>1===n
false

Yep, n is both equal and unequal to 1. But what’s up with that === operator? As many of you know, JavaScript is dynamically typed. If you check to see if two objects are equal using ===, JavaScript will try to figure out if they are the same type and, if not, try to get them to that same type. So, in the example above, n is a string with value of 1 and when you compare that to the Number value 1, they are the same.

But === doesn’t do the conversion. Instead, if it sees two objects aren’t of the same type, it says they aren’t equal automatically. This is more in line with how Python and Java work — i.e. statically typed languages. They call this an “identity operator”. Naturally there is a !== operator as well that returns true if the objects are not equal.

In Douglas Crockford’s awesome JavaScript presentations, he recommends always using the identity operators instead of the equality, unless you are purposely comparing to different objects. I tend to agree — not having automatic type casting should reduce bugs as well as improved performance.

YUI TreeView

As usual, it’s quiet around here because my life hasn’t been so quiet lately.  Lots happening at work and lots happening at home.  And I still don’t have my lawn mowed.

And one of my things I seem to be lacking on blogging is JavaScript. But that doesn’t mean I haven’t been using it!  No, I devote many hours a day with it.  I’ve been using the YUI components heavily and they are oh-so-pleasant to use.  They really take over the low-level work and let you concentrate on the important stuff.

Example: today I was playing with a TreeView object and making the leaves of the tree appear in a table when clicked. This is easier than I ever thought it would be.

First, I saved the leaf node with an ID and a label, because I wanted them both in the same row but different cells. I also wanted the row to be able to match to the ID so I could get to that row easily if need be. This is how I saved the node:

var nodeData = {label: mylabel id: myId}
 var txtNode = new YAHOO.widget.TextNode(nodeData, node ,false);

And this is how I took that data from the tree node and put it in the table:

     tree.subscribe("labelClick",function(node) {

            // if it doesn't have children, then it must be the text
            // of a rule
            if ( ! node.hasChildren() ) {
                // we are only going to add it once
               if (document.getElementById(node.data.id)!=null) {
                   return ;
                }
                var myTable = document.getElementById("tableID");

                var numRows = ruleTable.rows.length;

                var row = ruleTable.insertRow(numRows)

                row.id=node.data.id;

                var idCell = row.insertCell(0);
                idCell.innerHTML=node.data.id;

               var txtCell = row.insertCell(1);
               txtCell.innerHTML=node.data.label;

         }
       })

And that was that.

Powered by ScribeFire.

Gotta Love IE

I have been working on a site that uses a lot of [YUI](http://developer.yahoo.com/yui/) components — specifically Grids and Menubar. They were both CSS based, even though the Menubar required a touch of JavaScript, like so:

var oMenuBar = new YAHOO.widget.MenuBar(“menubar”,
{visible: true,
position: “static”,
autosubmenudisplay:true
}
);
oMenuBar.render();
oMenuBar.show();

function onMenuMouseOver(p_sType, p_aArguments) {
var oEvent = p_aArguments[0];
}

The page had been rendering just fine in FireFox. When I loaded it up in IE6, however, the page rendered correctly, but then a popup appeared, saying that it couldn’t render the page. When you clicked “Okay” it went to IE’s standard “Page Not Found” display.

Weird, I know.

I looked at the code and didn’t see anything that I could see that caused it. I went to the YUI Message Board and appealed to the experts. [Dav Glass](http://blog.davglass.com/) that sometimes that happens when IE hasn’t rendered the object that you are trying to access. The work-around is to use the [`onAvailable` or `onContentReady`](http://developer.yahoo.com/yui/event/#onavailable) methods. I looked at my code and quickly figured out that it must be the `menubar` div that isn’t rendered yet. So I changed it to this:

function MenuObj(id) {
YAHOO.util.Event.onAvailable(id,this.makeMenu,this);
}

MenuObj.prototype.makeMenu = function(that) {

var oMenuBar = new YAHOO.widget.MenuBar(“menubar”,
{visible: true,
position: “static”,
autosubmenudisplay:true
}
);
oMenuBar.render();
oMenuBar.show();
}

var menubar = new MenuObj(“menubar”);

function onMenuMouseOver(p_sType, p_aArguments) {
var oEvent = p_aArguments[0];
}

And wouldn’t you know? That worked.

Big thanks to Dav for helping me out!

Array Functions for JavaScript

I was going to go through the exercise of doing this myself, but it seems that [someone already beat me to it](http://erik.eae.net/archives/2005/06/05/17.53.19/). That’s okay — I’ll stand on the shoulders of giants.

These methods first check to make sure that they do not already exist on the Array object. If they do, they don’t overwrite it. If not, they create it.

So that allows you to do this in Firefox and IE:

myarray.forEach( function(item){
// item is in myarray
// so do something with it.

});

You also have `filter`, which is quite handy, too:

function isHidden(divname, index, array) {
var div = document.getElementsByTagName(divname);
return (div.style.display==’none’);

}
hidden = mydivs.filter( isHidden);

This works exactly like you would expect it to if you have arrays generated by JSON — in other words, like a charm.

JSON — not just for AJAX

I recently blogged on the evils of mixing Java and JavaScript in JSP pages but didn’t give any good ways around it.  I mean, you have a list or array in Java and you want JavaScript in the JSP page to access this data — how do you do that?

Let me introduce you to to Json-lib.

You’ve probably heard of JSON before and people rant and rave about it on using JSON with AJAX instead of XML[1].  And I don’t think there is anything wrong it that, but I didn’t want or need AJAX — I just need to move data from Java to JavaScript in a JSP page.  And JSON makes it oh so easy.

1. In your Servlet, get and arrange your data the way you like it.
2. Then using Json-lib make a JSONObject like so: JSONObject jsMap = JSONObject.fromObject(jobsMap);.
3. Put the string of that JSON object into your request.  You know what I mean: request.setAttribute("JSON_MAP",jsMap.toString());.
4. In your JSP page, just eval that string: var jobMap = eval(<%= request.getAttribute("JSON_MAP");%>.

And that’s it — your structure has been transfered from Java to JavaScript with no fuss nor muss.

The Json-lib jar is actually quite small. But the bad thing is that it has quite a few dependencies that their page doesn’t explain well and that doesn’t come with the download.  I needed to grab commons-beanutils, commons-logging, and ezmorph to get things rolling with Json-lib.  But it has sure been worth it.
[1] Then should it be called AJAJ?