Performing frequent training courses has given SitePen a chance to learn new ways to improve our training approach. Some concepts in JavaScript can be trickier than others and as we interact with the classes, we’re able to develop fun explanations for these tricky concepts. I’d like to share one of the explanations I developed at a recent training course.

A common phrase that results from these training sessions is “I didn’t know JavaScript could do that.” The first time we hear it is usually after we’ve covered how to work with functions in JavaScript, when we start showing how JavaScript allows us to use functions (in an approach termed functional programming). We try to conclude each part of the course with code examples that incorporate everything from the section we’ve just covered. At the end of our section on functional programming, we have the following example:

(more…)

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);
  }