Google and Yahoo have JavaScript APIs that let you perform searches. Wikipedia has a JavaScript API that lets you grab data from its pages. These APIs can be accessed cross-domain with a transport method known as JSONP. JSONP works by allowing you add a script tag to your page which points to a URL on their server. The server outputs JavaScript that will call a method (defined as part of the query string in the URL), passing it JSON-formatted data.

You’ll notice that these services are read-only. I don’t currently know of any cross-domain JavaScript APIs that allow you to write data in any meaningful way. An example of this sort of data would be a way, through JavaScript, to update your status on a social networking web site.

(more…)

Everyone who owns an iPhone (or who has been holding out for an iPhone 3G) is bound to be excited about a lot of the new things the device can finally do, particularly the introduction of third-party applications. But those of us in the web development community have been itching for something further still: good web applications on the iPhone. This means we need a suitable replacement for mouse events. And boy did we get them! Though at first the APIs seem a little sketchy, once you’ve learned them you should be able to do amazing things in your application.

(more…)

One of the biggest problems Dojo has when trying to attract new users is the fact that our community rarely promotes one method of writing code as THE WAY. Following suit, I’m not going to say that one method of doing things is better than the next. Ultimately, arguing that there is one catch-all solution to the problems coders face when developing for the web is one way to drive away users as soon as they realize that they want something more.

With this in mind, I’ll outline three strategies available with The Dojo Toolkit. Each offers different levels of control and different benefits. Hopefully, some of the negativity aimed toward some of these strategies is only because of a lack of understanding about their purpose. After some of that has been dispelled, I hope to kill any remaining bad feelings by showing that some of the things you might feel that the toolkit imposes on you can be fixed — with either a simple alias or a simple function.

(more…)

Dojo’s Ajax system provides much more than basic text retrieval. As you might have already discovered from the pages in the Dojo book on using both text and JSON versions of Ajax requests, as well as the API page for dojo.xhrGet, the handleAs parameter lets us specify how we want the returned data to be parsed.

From the API page, on the handleAs parameter:

Acceptable values are: text (default), json, json-comment-optional, json-comment-filtered, javascript, xml

What you may not know is that the handleAs parameter is merely a way of specifying what plugin to use. Knowing where these plugins are, how they work, and how they can be adapted to suit your project will allow you to make repetitive tasks easy and less error-prone.

(more…)

I was first exposed to metaclass programming through JavaScript, though I didn’t realize it. When I started digging into the guts of Django’s ORM system, I learned how metaclass programming in Python worked and discovered I’d been doing something similar in JavaScript for a while.

So what is it? Some great articles on metaclass programming turn up in Google and are worth a read. But for those of you that would rather just get down to business, I’ll try to summarize the idea really quickly, focusing on what we’re going to be able to do with Javascript.

(more…)

Creating a subclass in JavaScript is an art form. You have to create a function, link the prototype of your function to the prototype of the superclass function, and then make sure that you call the superclass function, taking special care to make sure that it runs in the same context as your function.

Here’s your problem: you just want to change ONE property in this class, but you can’t change it on the actual class because that value would now be used across all instances of that class. So in order to make it happen, you go through all the messy, painful steps described above.

(more…)

This is a continuation of my previous post A Fine Line Between Abstraction and Obfuscation and, of course, deals with the same material.

JavaScript is flexible in almost every way, and many people end up either abusing the flexibility, or creating strategies of overcoming the flexibility that only create confusion and messy code. I’d like to go over one of my favorite topics today, JavaScript’s function signature, although lack of a function signature is probably a better way to say it. You’ll see that can employ some strategies that can solve these problems without increasing the amount of code you have, while at the same time, providing context for those using your code in the future. Even if you don’t use everything I’m setting out below, I hope it will reveal what to be cautious of, and help you create meaningful solutions of your own.

(more…)

Introduction to Part 1

By the time you have written your abstraction layer, you have essentially written your own framework. Chances are, you are not a good framework writer, and it’s going to suck, and you are going to realize that one or two versions down the road and re-write it. © RedMonk in Java’s Fear of Commitment.

While there is a lot written on how difficult it is to write a good abstraction layer, there is very little advice on how to avoid the worst evil of the abstraction layer: obfuscation. As I scoured the internet looking for any discussion on this topic, my search results were a lot more sparse than I was expecting. There is a very succinct blog entry by Rhett Maxwell that turned up in my results that summarizes some of what I’d like to say in a single sentence: Most of the books out there that teach OO design talk about Abstraction, but they do not warn about Obfuscation at all. Its a shame.

And to those of you wondering why this type of obfuscation is a problem, let me clear it up. Obfuscation at its most harmless simply confuses people. Obfuscation at its worst makes people stupid. When the most brilliant programmer can no longer figure out how to get from point A to B, even though they are right next to each other, all their genius is useless.

JavaScript is incredibly susceptible to becoming accidentally obfuscated. In the next month or so, I want to go over various common methods of abstraction that I have seen widely used in JavaScript and discuss how and why they can lead to obfuscation.
(more…)

I’ve been following John Gruber on Twitter, who just noticed that the iPhone update (1.0.1) now updates Safari with the ability to send key events. Fantastic! 2 steps forward.

But, onkeyup is broken. You see, the onkeyup event is supposed to be called after a key event has officially propagated through the page. This is very important, because by the time onkeyup gets called, the page should have adjusted itself for this newly inserted character. For example, in a text input box, when you press a key it doesn’t show up in that input box until after onkeydown and onkeypress have been called, but does show up before onkeyup is called. Pretty much the whole reason that onkeyup hook exists at all, is so that you can be notified after this change has happened. The iPhone sends onkeyup before the page has been updated. 1 step back.

What this means is that sites that rely on using the onkeyup event to tell what is in their text entry box will break. There is a simple solution though! (other than having to find the key value in the event object) Just use setTimeout, with a timeout of 0 and you’ll be able to see the proper value. For example:

  input.onkeyup = function(e){
    setTimeout(function(){ alert(e.target.value); }, 0);
  }

Well, the plan was to go through every type of input object, button, and image in Safari on my shiny new iPhone and make notes about what functions were available, how event handling works, and any other fun little goodies that came along. I started out with the good old text input box, and after an hour or two of executing functions in all sorts of different orders and being seriously freaked out a couple of times, I’m worried about the pretty severe limitations of one of the most basic widgets of the web browser:

• When the input does not have “virtual keyboard” focus, calling its focus function calls its onfocus function, but does not give the input “virtual keyboard” focus
• When the input does not have “virtual keyboard” focus, but you’ve called its focus function, calling its blur function will call its onblur function. When the input does have “virtual keyboard” focus, calling its blur function does absolutely nothing (which breaks some scripts that prevent input by blurring on focus).
• When the input does not have “virtual keyboard” focus, calling its select function does nothing, until you scroll or zoom in on the page, at which point it calls both its onfocus and onblur functions. When the input does have “virtual keyboard” focus, calling its select function does absolutely nothing.
• Calling its click function calls its onclick function as expected.
• Selecting an input box fires: onfocus, onmouseover, onmousedown, onmouseup, onclick, and sometimes onmousemove
• Selecting the next item on the page fires: onblur, and (conditionally) onchange, but still no key events.
• Clicking the “Done” button in the “virtual keyboard” fires: onblur, and (conditionally) onchange, but still no key events.
• The only key that registers any key events is the return key.