Fangs

I just discovered that the Fangs extension for Firefox hadn't actually gone stale after all! I would guess, that like some other extensions and themes I've seen around, it seems (unfortunately) easier to not even bother with the official repository.

Fangs comes in handy when you need to quickly and easily get a rough idea of what a given page would sound like when using a screen reader. When I need to get a much better idea of the usability of a web application when doing things text-only, I generally use lynx to actually interact with the page. Using a screen reader, of course, lets you know exactly how it will (or won't) work, but for those who don't use screen readers day-to-day, this generally has cost, learning curve, and support implications (anyone know a decent Mac screen reader?).

I spent today writing more of Chapter 2: Usability, specifically the Semantic Markup section, so having Fangs back definitely made things a bit easier. I tried using MacOS X' Voice Over Utiliy for a few, but it seems altogether too clunky and not accurate enough for use with Safari. It also seems to read by page layout order, rather than the order of the markup, which sounds exceedingly horrible when you have a two-column layout like this one. I want it to work, and I sincerely hope I just missed a setting somewhere...

Many thanks to MSDN and VMWare

I can finally open the Word templates Debra from Prentice Hall sent for me to use! It took installing Office (2007, with a completely re-done, strange interface) in Windows XP in VMWare's Fusion Beta release (since I never got Parallels running happily), but it worked. The templates didn't work in Office X for the Mac, but I dragged them over to my shiny, new VMWare image and they opened right up.

Now (well, sometime in the next few days) to actually apply the styles and submit Chapter 1. Debra bugged some people for me and got some styles to apply so that I can have syntax highlighting in each of the code samples throughout the book! That should help make things much more legible. I know I would prefer it that way, and Terry reminded me of the importance of readability, prompting me to ask for it in the first place.

On a side note, I've found that if you use Safari using ATSU for text rendering to read this blog, all inline <code> tags have an effective width of 0px with a displayed overflow. Weird, and very annoying, since I rather prefer that enabled.

Chapter 2 excerpt

Ajax usage has exploded in a manner resembling the upswing of such web technologies as:

1. The blink and marquee HTML tags1
2. Animated GIFs
3. Applets
4. The table HTML tag
5. Flash

Each of these - admittedly, for the most part, less technical - exploded into usage to the point where (to varying degrees) most web designers and developers have reflexive, knee-jerk reactions upon the mention of them. The original usefulness of each technology now has an overshadowing of the preconceived notion that they cannot get used in any way beneficial to the general user2.

As such, Ajax-based functionality fits best where it makes a given task easier for the user, rather than replicating functionality easily achieved by simpler, faster-developed means. Using half a dozen JavaScript files, numerous CSS files, and several Ajax calls for content, simply in order to render a company home page uses up a lot of time and memory for very little by way of benefiting the user3, and actually makes the user wait much longer than necessary while using much more of your server resources than necessary.

In contrast, adding a light-weight content loading script that displays a blog's comments when requested by the user reduces loading time by using less bandwidth, and keeps the comments in better context rather than jumping to a comment page with (in some cases) drastically different design.

• 1 Neither of these tags actually exist within the HTML specification, but browsers have supported them for years, regardless.
• 2 With the exception of the blink and marquee tags, which actually have specific instructions against their usage written up by the W3C.
• 3 This does not mean that the referenced technology does not ever have benefit to the user, just that this particular use case does not benefit the user enough to warrant its usage.

Altogether, rather neglected JavaScript functions

Terry's pointing to David Kellogg's post on JavaScript's watch() (coupled with some prompting from Jason) inspired me to add call and apply. At this point, both of these functions have made it into integral pieces of code, both for my own projects and for the book. Calling things like the following makes it infinitely easier to write OO JavaScript:

window.addEventListener('load', new Function("Throbber.prototype.attach.apply(throbber, arguments);"), false);

This needs to happen, rather than...

window.addEventListener('load', throbber.attach, false);

...as JavaScript's this can work in strange, mysterious ways to those uninitiated to prototype-based languages. In the first code block, this would return a reference to the throbber instance of the Throbber class. The the second code block, this would return a reference to the window object.

Edited (12/19/06): I just found that Bret Taylor wrote about this in July. How did I not find his site until now?

A fantastic idea!

Goodwill just opened Good Bytes Cafe in San Antonio, an internet cafe built around accessible computer/internet access. Things like this not only help those who will use them, but also people who will see it in action. Most people never think about how they would use computers if they lost their sight, or the control necessary to precisely control a mouse.

Edited 01/18/06: The article has expired, so have a link to the actual site for Good Bytes Cafe.

Updated sample and ajax.lib.js

The quick example now has some basic formatting and a link to run it.

More interestingly, from my perspective at least, I've updated the AjaxRequest and AjaxRequestManager objects.

The AjaxRequest object now has four events (open, send, load, and abort), and now has an actually readable onreadystatechange listener by using a quick trick in order to keep this references intact:

this.xhr.onreadystatechange = new Function("AjaxRequest.prototype.stateChanged.apply(requests["+id+"], arguments);");

The AjaxRequestManager now emulates support for event listening, in that it can accept addEventListener and removeEventListener calls. But instead of dispatching events, it auto-adds the listeners to each of the AjaxRequest objects it creates. This makes it a lot easier to write, for example, a Throbber object, since it can get added as a listener to each request in order to keep an eye on things while keeping things nice and loosely coupled.

Edited so you can read the code...

Current state of the Ajax library

A little large to post here, but you can check out the source and an example, where the usage boils down to:

this.request = request_manager.createAjaxRequest();
// For this example, this does nothing, but demonstrates how to set GET parameters
this.request.get = {
  one : 1,
  two : 2
 };
this.request.addEventListener('load', new Array(this, this.ran));
this.request.open('GET', 'xml.php');
return this.request.send();

In order to run the code, a simple new SimpleDemo().run(); will do the trick from Firebug (side note: sample only tested from Firefox - let me know how it fares in other browsers).

Basically, I need to ensure that usage like this makes things easier to read and port to other libraries. I honestly don't care if anyone actually uses this library, I just want the usability and abstraction to get through. The Ajax portion weighs in at just under seven kilobytes, including white-space, comments, and full names so you can actually read it, and I have every intention on keeping it that way. I've included a reference to Firebug Lite, just in case you don't have the full version installed.

Edit: okay, so the source code viewing works in Opera, but not Safari, and calling run(); from Firebug Lite pretty much does squat in either of them. Editing will commence, but I will still greatly appreciate any feedback and criticism.

Table of Contents

At least, as of right now. Suggestions? Comments? Complaints? Just know that some of these chapter sections mean more as notes to me than actual chapter sub-headings. Ask questions, though.

1. Introductions1
   • Background Info
   • Intentions
   • Prerequisites
2. Usability
   • Interface vs. Showcase
   • User Expectations
   • Feedback and Indications
   • Semantic markup
   • What CSS and JavaScript have in Common
3. Accessibility
   • Section 508 and WCAG
   • Screenreaders Can Handle AJAX
   • Unobtrusive JavaScript
   • Assuming Nothing
   • Designing with Accessibility in Mind
4. Client-side Application Architecture2
   • Objects and Event Triggering
   • Model-View-Controller Design Pattern
   • Event-driven Application Development
5. Debugging Client-side Code
   • Validation, Validation, Validation
   • Code Profiling
   • Browser Tools and Plugins
   • Unit Testing
6. Performance Optimization
   • Bandwidth vs. Latency
   • Server-side Cache
   • Client-side Cache
   • Content Negotiation
   • Memory Usage
7. Scalable, Maintainable AJAX
   • General Practices
   • A Multitude of Simple Interfaces
   • Dense, Rich Interfaces
8. Server-side Application Architecture
   • Designing Applications for Multiple Interfaces
   • Model-View-Controller Design Pattern
   • Using the Factory Pattern with your Template Engine
9. Keeping a Web Application Secure
   • HTTPS
   • SQL Injection
   • XSS
   • XSRF
   • Don't Trust the User
   • Don't Trust the Server
10. Documenting
    • Yes, You Need To
    • API Documentation
    • Internal Developer Documentation
    • 3rd Party Developer Documentation
11. Game Development
    • Single Player
    • Turn-based Multiplayer
    • "Real-time" Multiplayer
12. Conclusions
    • Remember the Users
    • Design for the Future
    • Develop for the Future
    • Final Thoughts

• 1Done! Just need to run it through the publisher's template (since I edit in vim and manage in subversion) and send it on its way.
• 2First draft done! At least, as I wrote it for the sample chapter. I need to do another once-over, getting its coherency in place, so it keeps in line with the rest of the book, then run through the publisher's template, but I have most of the content and code samples there.

Recommended reading (a small excerpt from the intro)

The following books (in no particular order) all have high recommendations from editors and the developer community alike, and any of them should serve as very good lead-ins to the chapters that follow.

• Ajax in Action, by Dave Crane, ISBN 1932394613

  "Web users are getting tired of the traditional web experience. They get frustrated losing their scroll position; they get annoyed waiting for refresh; they struggle to reorient themselves on every new page. And the list goes on. With asynchronous JavaScript and XML, known as "Ajax," you can give them a better experience. Once users have experienced an Ajax interface, they hate to go back. Ajax is new way of thinking that can result in a flowing and intuitive interaction with the user.

  "Ajax in Action helps you implement that thinking--it explains how to distribute the application between the client and the server (hint: use a "nested MVC" design) while retaining the integrity of the system. You will learn how to ensure your app is flexible and maintainable, and how good, structured design can help avoid problems like browser incompatibilities. Along the way it helps you unlearn many old coding habits. Above all, it opens your mind to the many advantages gained by placing much of the processing in the browser. If you are a web developer who has prior experience with web technologies, this book is for you."

• Professional Ajax, by Nicholas C. Zakas, ISBN 0471777781

  "Professional Ajax discusses the range of request brokers (including the hidden frame technique, iframes, and XMLHttp) and explains when one should be used over another. You will also learn different Ajax techniques and patterns for executing client-server communication on your web site and in web applications. By the end of the book, you will have gained the practical knowledge necessary to implement your own Ajax solutions. In addition to a full chapter case study showing how to combine the book's Ajax techniques into an AjaxMail application, Professional Ajax uses many other examples to build hands-on Ajax experience."

• Ajax Patterns and Best Practices, by Christian Gross, ISBN 1590596161

  "Ajax Patterns and Best Practices explores dynamic web applications that combine Ajax and REST as a single solution. A major advantage of REST is that like Ajax, it can be used with today's existing technologies.

  "This is an ideal book whether or not you have already created an Ajax application. Because the book outlines various patterns and best practices, you can quickly check and verify that you're building an efficient Ajax application."

• Understanding AJAX, by Joshua Eichorn, ISBN 0132216353

  "Building on what you already know, this fast-paced guide will show you exactly how to create tomorrow's richest, most usable Internet applications. Joshua Eichorn teaches through sophisticated code examples, including extensive back-end sample code based on PHP, the world's #1 server-side language.

  "You won't just learn how to code AJAX applications: Eichorn covers the entire development lifecycle, from use cases and design through debugging. He also presents detailed application case studies, including a start-to-finish update of a non-AJAX application that addresses everything from feature improvements to changing usage patterns."

The following websites also have a wealth of information available, most of which should prove useful enough to bookmark for easy access.

• W3C
• mozilla developer center
• Quirks Mode
• css discuss

I'll also post an edited version of my bookmarks, since I use the references constantly for my day-to-day work, let alone when I need to look something up for the book. I just wanted to post the "I visit at least one of these sites almost every time I look up anything related to an Ajax problem" links. When I see others post a list of most-used references of theirs, I generally find at least one I didn't know about or look into enough to realize its full value.

Contextually dispatching events

I just realized that I could implement EventDispatcher.prototype.dispatchEvent as (difference emphasized):

dispatchEvent : function(type, event) {
 if (this.events[type]) {
  for (var i in this.events[type]) {
   if (typeof this.events[type][i] == 'function') {
    this.events[type][i](event);
   // Accepts an array of the contextual object and the function to call
   } else if (typeof this.events[type][i] == 'object') {
    this.events[type][i][1].call(this.events[type][i][1], event);
   }
  }
 }
}

This makes it much easier to keep this references happy and I can't believe I didn't think of that until just now, since I used almost the same code to call parent object methods from a child that had overridden the method. So now you can create listeners from within object methods like this:

myeventdispatcher.addEventListener('load', new Array(this, this.myLoadEventListener));

or this:

myeventdispatcher.addEventListener('load', new Array(this, MyObject.prototype.myLoadEventListener));

Side note: I also realize I need to find a way of posted syntax-highlighted code consistently and easily. The code I had posted on Simple Event Generation came from copying the source into Kate, exporting the highlighted code as HTML, and pasting the mass of spans into Blogger.

First excerpt - technologies used in the book

The example code will use the following technologies for each application layer:

1. Webserver - Apache's HTTPD1 version 2.0. As of this writing, the Apache foundation has released the 2.2.* branch as the primary stable branch. The example configuration directives in the book should carry over without much deviation to the newer version.
2. Database Server - MySQL Database Server 5.0. The 5.0.* branch introduces a wealth of useful functionality and stability over previous versions, including stored procedures, triggers, views, and strict mode. As of this writing, they have released the 5.1 branch as a beta.
3. Server-side Scripting - PHP 5.2. While PHP 6 brings global Unicode support to PHP2, along with cleaned up functionality, closer integration of the new PDO database extensions, even more drastic improvements to the object model, and for some reason goto, the PHP group has only made it available from source so far. It has much development left on it, but should see greater adoption rates than PHP5 has seen so far. That said, PHP 5.2 brings an input filtering extention, a JSON library enabled by default, greater ability to track file upload progress, vastly improved time zone handling and more.
4. Markup - XHTML 1.1. While XHTML 2.0 has reached its eighth public working draft, XHTML 1.1 maintains HTML compatibility while strictly enforcing XML, modules, and the progression to XHTML 2.0. Unfortunately, Internet Explorer does not in actuality support XHTML, rather it renders it as HTML. This does make quite a difference and holds many developers back from fully embracing the XHTML modules available to them. As such, the markup directly rendered in the browser will have the Content-type: text/html rather than application/xhtml+xml as recommended by the W3C. Technically, the specification3 strongly recommends against using text/html with anything beyond HTML 4 or XHTML 1.0 (HTML compatible). However, it does not forbid it, as it does with using anything aside from text/html with HTML 4.
5. Style - CSS 2.1. CSS 3 introduces much of the styling and layout abilities asked for years ago and eagerly awaited by web designers, however it has not reached a stable enough point for many of the browsers to support any more than some of the basics4. Even with the much-anticipated release of Internet Explorer 7 (refered to as IE or IE7 from hereon in), IE still fails completely support even the CSS 2.0 specification. The IE development team worked very hard to improve the state of IE's CSS support and, while they did a fantastic job, they didn't quite make it all the way there. Since many resources5 exist already covering the hacks and fixes necessary to force IE6 and IE7 each to follow your design, this book will not go into detail of how to achieve complete, pixel-perfect, cross-browser designs.
6. Client-side Scripting - JavaScript 1.5, together with the XMLHttpRequest object, which at time of writing, only exists as an informally agreed upon object and the very beginnings of a specification6. Many Ajax-type web applications and sites use Adobe Flash for text and XML communication with the server, Flash development gets too specific for coverage in this book. Many of the same principles and much of the architecture covered still apply, but the implementation differs. ActionScript, also an ECMAScript implentation, actually shares the syntax, object model, and often even development tools with JavaScript, so while the XMLHttpRequest object does not exist in ActionScript, and the working DOM differs, much of the other sample code should look very familiar and easy to follow.

Familiarity, at least to the point of understanding enough to port the code into your language of choice, will definitely help, though this book aims to provide the methodologies, architectures, and patterns which you can implement in your own rich web application, no matter what technology you use to drive it. The technologies listed above have several benefits. They can all get downloaded and/or used for free, on a wide range of platforms, tested in a wide range of browsers, and have large user bases and online communities ready and willing to assist you if you run into any problems with the technology chosen.

• 1 http://httpd.apache.org/
• 2 PHP does not technically pay attention to the bytes of strings. It just regards them as a numbered list of bytes. While this has the benefit of passing UTF-8 strings through PHP (even without the Multi-byte String library) unharmed, side effects can show themselves in the strangest, often most devestating, places in your application.
• 3 http://www.w3.org/TR/xhtml-media-types/
• 4 Rounded borders, multiple background images, column layout, text shadows, and transparency have all made it into the Webkit project. As of this writing, the Mozilla Gecko engine and Opera's rendering engine have also both implemented most of these.
• 5 http://css-discuss.incutio.com/, http://blogs.msdn.com/ie/
• 6 http://www.w3.org/TR/XMLHttpRequest/ as part of the Web API Working Group's activities.

Simple event generation

In an effort to keep each chapter and its included code samples as relevent as possible to the context around it, I decided that a toolkit made the most sense. I also decided to simple write the toolkit and include it for the following reasons:

1. I haven't used any of the ones out there yet for long enough to use them to correctly accomplish exactly what I need without coding the samples specifically for that particular toolkit.
2. I needed a toolkit anyway for other things I work on and (since I'll release this under the BSD License), I can write it and use it anywhere.
3. The toolkit will only need to cover a comparatively limited set of features, so I won't re-write all of Dojo, for example.
4. Incuding code samples like the following reinforce the overall method of development.

The following implements very simple, yet effective, event listening. Just extend the EventDispatcher with whatever object has events (form handlers save, fail, delete, load, clear, etc.) and extend the CustomEvent object to fit your needs. This gets used extensively throughout the book in order to simplify the objects through encapsulation.

function CustomEvent() { }
CustomEvent.prototype = {
 type : 'custom'
}

// Custom EventTarget equivalent
function EventDispatcher() { }
EventDispatcher.prototype = {
 // An object literal to store arrays of listeners by type
 events : {},
 
 // If it supports the type, add the listener (capture ignored)
 addEventListener : function(type, listener, capture) {
  if (this.events[type]) {
   this.events[type].push(listener);
  }
 },
 
 // If it supports the type, remove the listener (capture ignored)
 removeEventListener : function(type, listener, capture) {
  if (this.events[type] == undefined) {
   return;
  }
  var index = this.events[type].indexOf(listener);
  if (this.events[type][index]) {
   this.events[type].splice(index, 1);
  }
 },
 
 // Cycle through all of the event listeners, passing the event to the callbacks
 dispatchEvent : function(type, event) {
  if (this.events[type]) {
   for (var i in this.events[type]) {
    this.events[type][i](event);
   }
  }
 }
}

Edited so you can read the code.

12/8/06 - Edited to fix dispatchEvent to actually work.