A Few Ajax Gotchas At Jalecode

Andrew Sutherland offers a few Ajax Gotchas/Tips. I’ll add some comments.

  • Escape content with encodeURIComponent() which is superior to escape.

  • XMLHttpRequest’s readyState tells you how far the request has progressed. MM: If you’re confused about readyState‘s transition from 0 to 4, you have good reason to be. Read the recent posting and comments on David Flanagan’s blog, and you’ll learn that 2 and 3 are ambiguous to the point of being unusable. Essentially, you want to wait for either 4 or timeout, and probably ignore everything else.

  • Permission Denied” for XMLHttpRequest is usually due to trying to call another domain. MM: The standard security policy is that requests can only be sent to the originating server, just like the traditional policy for Java applets. To get to another domain, you can set up a Cross-Domain Mediator. This security issue has become interesting with the growing popularity of Single Page Applications (SPA). What can an HTML page sitting on you hard drive access? All domains or no domains? It would certainly be convenient if it could access the web at large. I don’t think it can access any domains on standard browsers, but it’s still possible if the user wants it to happen. Here’s what Steve Yen (TrimPath) says on this issue: “I’m shooting for now to have explicity user-driven synchronization working, which my experiments lead me to believe is workable.”

  • MM: Finally, I’ll add another gotcha-inspired tip to Andrew’s collection: Set content type to XML (in the case where you want to treat the response as XML), e.g. in PHP, header("Content-Type: text/xml");.

A Fading Habit

I’ve noticed that I’ve recently habitualised the Yellow Fade Technique, or what the Ajax patterns refer to as One-Second Spotlight.

The typical Fade example is a form field. When you change it, the field is suddenly highlighted, then gradually fades back to its original form. This tells the user that “the computer” knows something’s happened, and also serves to draw their attention to a particular element.

This is one of those things that could have been big years ago, but never happened. Despite the fact it’s only become popular recently, it’s all quite simple from a technical perspective, even more so with the new libraries coming out. I created a couple of demos a while back – one is powered by Scriptaculous, the other uses a custom-built fading engine. The first demo runs opacity through a sequence, the second demo does the same to colour, rather than opacity.

In the Scriptaculous case, running the effect is mind-numbingly simple to invoke:

new Effect.Appear(“defaultTimeLabel”);

And likewise in the case of my custom fader (which lets the user specify colour preferences):

fader.fade(defaultTimeLabel, $(“startColor”).value, $(“endColor”).value);

Anyway, I’ve lately been coding some more dynamic DOM manipulations, and it’s occurred to me that I now ask myself, whenever I add or remove an element, if I need to run an effect. Having scriptaculous handy makes it so easy to do. So fading started off as a bit of a novelty and is now standard practice.

I can hear people saying, “not the blink tag” and re-living 1995-esque motion sickness. That will definitely happen on some Ajaxian sites, but let me clarify that I’m only asking the question each time a change comes up, not actually implementing the change. Apps using the One-Second” visual effects include TiddlyWiki and Backpack (one of the first uses). They show how it can be used effectively and without going overboard.

Of all the new JS libs coming out, I haven’t seen any that augment or replace basic XHTML DOM manipulation. If one does emerge, I’d like to see it provide support for auto-effects and perhaps a parameter to indicate the effect. e.g. el.hide(Effect.FadeOut); el1.add(el2, Effect.BlindDown).

Reading Open-Source Code

Dave Crane looks into some Scriptaculous code. The main point is that Scriptaculous is easy for novice JS programmers to use, but the source code would be difficult, for novices at least, to understand. Which raises these questions:

So, going back to the bigger picture, here’s something for the authors of JavaScript libraries to consider. How much of a gap are you creating between using your library, and being able to modify or enhance it? Does such a gap present a barrier to its uptake? Should good code be there to be read as well as executed?

In theory, the implementation of a library shouldn’t matter to developers using it. That’s because a good library should offer components that are open for extension, but closed for modification – the open-closed principle. Thus, you should be able to treat the library as a black-box and only care about the API it presents – you never have to maintain it, so why read the code?

But it’s usually not so simple. You might not need to change the code, but you do need to understand it. In an ideal world, there would be abundant documentation. But agile says that all that documentation is valuable, but self-documenting code is much more valuable. In similar vein, the availability of code is often justified as a reason for open-source projects to include less documentation (among other benefits). So open-source code had better be understandable, ideally self-documenting, but at least well-commented.

I have used (by “used”, I mean “wrestled against in a cage match”) a couple of very prominent Java EE frameworks where implementation code is confusing and badly in need of refactoring, with most of the code comments in “TODO” and “Weren’t you going to fix this?” territory. I was stuck and documentation was insufficient, so I could only turn to the source code for help. And that’s actually a pretty good place to work out what’s going on anyway. But, alas, the code did not come to my aid. ** Perhaps that’s the natural consequence of an open-source project becoming a startup with a support-based revenue model, but it makes a mockery of the code-as-documentation argument for open-source.**

The Scriptaculous implementation is good for anyone who knows Javascript, which is all you could hope for … just because it’s API is simple enough for novices, doesn’t mean its implementation has to be. In fact, the implementations of “Puff”, “Fade”, and so on, are actually extensions of the base functionality, and any developer could create their own effects in the same way. The Effect framework is an example of how Javascript can provide decent support for Domain-Specific Languages, in Scriptaculous’s case, a grammar of visual effects. Also, if only want to use an existing effect, but with a little variation, some of them accept an options specification.

DHTML Super Mario Bros!!!

Ajax, AjaxPatterns, DHTML, Gaming, Patterns, Web

Super Maryo Bros in pure Javascript – check it out! Just like DHTML Lemmings, only Japanese and based on a game I was once much more obsessed with! Quick pattern mining:

  • The dominant pattern in any Ajaxian arcade game is Sprite.
  • Some cute use of Popup on the initial page. I like how this page works – it’s like a mashup between a splash screen sequence and a “training wheels” tutorial.

Unfortunately, I can’t get it to work too well on Linux Firefox. The Japanese instruction on the bottom of the page says “Dash [Ctrl] Jump [Shift] [Space]”, but only Space seems to work here. Also, I can’t seem to use a two-key combo to jump diagonally, which sort of ruins any chance of finally getting past Level 6-3.

I’ve added to the growing collection of games and toys on the Ajax Examples page. Also related is the recent blog entry on multiplayer gaming.