When JavaScript Conventions Aren’t Conventions

In experimenting with Dashcode last night using the introductory tutorial provided by Apple, I noticed that in their example, they build a URL dynamically:

var dsource = dashcode.getDataSource("list");
var name = dsource.selection().valueForKey("name");
document.location =
    ("http://www.google.com/search?client=googlet&q="
    + name);

But your first thought when looking at this may be (as was mine), “what if there are spaces or other characters in the “name” value that are not legal in an URL?

So then I set out to use one of the standard functions for escaping URIs: encodeURIComponent.

Unfortunately, when I entered the function I spelled it encodeUriComponent using camel case, which is what I thought was appropriate in this situation. Evidently not. I even was referencing good ol’ w3schools on the subject too.

But once again it kind of gets back to the whole “was it getElementByID or getElementById?” dilemma. And, unfortunately, unlike Visual Studio, there wasn’t IntelliSense in this case.

So then I set out looking to see why it was bombing, thinking that it was maybe a problem in Mobile Safari, like it didn’t support the function. I switched to escape and that worked just fine.

Then I looked more closely at the w3schools page and noticed the difference.

DUH.

Felt real stupid too.

But when using the function with the correct spelling/capitalization it worked just fine. Whew!!!

I guess I should have just copy-n-pasted.

😉

Leave a comment

Your email address will not be published. Required fields are marked *