Vishful thinking…

Writing better javascript – Part 1

Posted in javascript by viswaug on November 18, 2008

Since I have taken a deep dive into the world of JavaScript programming for a while now, I thought I would start a series of posts with some of the lessons learnt and some good JavaScript programming practices I follow to make my life easier. Here goes the first post …

Always use the “===” operator over the “==” operator unless you explicitly want to.

The difference between the “===” operator and “==” operator is that the “===” makes sure that the types of the values you are comparing are also equal whereas the “==” operator doesn’t. Well, what does that really mean? Well, take the example below

var test = “3”; //the variable test contains the string “3”
if(test === 3) {    alert(“‘===’ evaluated to true.”);}
if(test == 3) {    alert(“‘==’ evaluated to true.”);}

In this case “test === 3” comparison will evaluate to false because the variable ‘test’ contains the string ‘3’ and it is being compared to the number 3. Whereas “test == 3” comparison will evaluate to true because the ‘==’ operator ignores the types of the values being compared.

In most cases, you will want to do a ‘===’ comparison and not the ‘==’ comparison. Getting into the habit of always using the ‘===’ operator will help to avoid certain error conditions which are normally hard to locate and debug.

Error handling for the ESRI JS API

Posted in ArcGIS, ESRI, javascript by viswaug on November 9, 2008

Writing good software means handling errors properly so that the user can notified of the error and appropriate action can be taken in response to the error. I was looking to doing the same for when I was using the ‘QueryTask‘ and other tasks in the JS API that make ajax requests back to ArcGIS Server. The ‘execute(parameters, callback?)’ method on the QueryTask provides a way to specify a function that will handle the results from the server. The call back function is only called when the ajax request is successful. But what if the ajax request failed? How would you handle that? If you are using FireFox with the FireBug add-on, then you would notice that an error message gets logged to the console in FireBug. In my application, I block access to the map when the QueryTask is being executed and until a successful response is received from the server. But I needed a way to be notified when the QueryTask failed so that I could unblock the map and inform the user of the error. After some sleuthing around the JS API, I was able to handle the errors that happen in the JS API. The Dojo library includes a publish & subscribe event system which allows for anonymous event publication and subscription. Using this functionality any piece of code in JavaScript can publish an event with a specific name and all interested parties can subscribe to the event using the event name. And subsequently unsubscribe when not needed.

dojo.publish(Topic Name [string], Arguments to Pass to Subscribed Function [array])

handle = dojo.subscribe(Topic Name [string], Context of Linked Method [string or null], Linked Method [string or function])

dojo.unsubscribe(Handle [handle object])

Well, the JS API leverages this and publishes an event named ‘esri.Error‘ whenever an error happens during an ajax request. So, you can subscribe to the ‘esri.Error’ event that is published by the JS API right before calling execute on the QueryTask and unsubscribe when the results are successfully returned or if an error occurred. This should suffice for most cases but if you are a stickler, you will soon realize that if you execute many QueryTasks simultaneously the error subscription only lets you know that an error occurred and the error message. It however does not let you know which one of the QueryTasks failed. Another way the error can be handled is by temporarily overwriting the ‘‘ function and resetting it after the request has returned successfully or with an error. But this way also has similar drawbacks. The best solution to the problem would be for the execute method on the QueryTask to take an error handler function as another parameter.