Basic Ajax Examples. Learn Ajax and Explore.
|Assistive Search||Supporting the "search as command-line" idea.|
|Chat/Wiki||Edit the wiki without clicking Edit or Save.|
|Shop||E-Commerce App with No-Submit Lazy Registration|
|Synchronised Drilldown||Ajaxian drilldown menu synchronised with the publicly-editable Ajax Patterns Links Page.|
|Time Refresh||Customisable Fade Effects|
|Unique URL Demo||Yes, deep-linking to Ajax apps is possible.|
|Boldfaced entries have numerous refactorings.|
These are a bunch of demos to illustrate the Ajax patterns and the book, Ajax Design Patterns by Michael Mahemoff. The Ajax patterns are design guidelines summarising the lessons people have been learning while experimenting with Ajax. The demos here are coded and copyright Michael Mahemoff, released under a the same Creative Commons license as the patterns.
The site continues to evolve following the book's release, with new demos such as favicon, widgets, and cross-domain iframe communication.
Serious development nowadays is more about organic growth than big upfront design. Consequently, patterns are refactoring tools. To demonstrate one pattern at a time, the demos here show how you can introduce a pattern to refactor the system.
So at the top-level (here), you have links to several basic demos. Each demo is effectively a tree structure - there's the basic demo on top, and a structure of refactored versions underneath. If you're looking at "sum/xml/cache", you're looking at "Basic Sum", refactored to use XML, then refactored again to use a cache. And you'll notice there are deeper levels, which constitute further refactorings. Each refactoring from one version to another generally represents a single pattern being introduced. More verbose explanation here.
I probably feel the same way - there's been times when I've thought "this demo would be much cooler if it had Unique URLs", etc. In some cases, I have created a deeper refacoring level to add something in. But in mosts cases, again, it comes down to focusing on just one pattern per refactoring, and that limits how much can be done.
First, a note on portability. I'm only testing this on Firefox 1.0.5 and IE6. I realise it's important for real-world Ajax applications to support Safari and Opera and other popular browsers, and it's also important to degrade gracefully for older systems. However, those are cross-cutting concerns, and the demos here are supposed to be as minimal as possible. Given these are toy systems, I'd rather create more demos than devote large quantities of time to coding and testing for portability concerns.
Okay, so you're using a recent Firefox or IE, and it still doesn't work? Or you have a general comment? I'm keen to find out - please mail me, add a comment to the pattern's discussion section in the wiki, or add something to the feedback form on the page in questions (which goes to a public RSS feed).
Yes, most demos only have a couple of lines explanation at best. That's because, in most cases, there's a long explanation in a corresponding pattern, linked from the demo. I'm striving to add better summary info, so you can happily browse the demos to get a feel. And I also need to ensure every demo links to the patterns.
That's because I prefer self-documenting code to code comments. I'll concede the code here isn't always self-documenting, and there aren't the usual unit tests to compensate for comments. However, there's something else: the pattern documentation, which walks through the code. To paraphrase the agile manifesto: Code comments would be valuable, but annotated walkthroughs are more valuable.