AJAX - The Cool Intermediary:
The AJAX engine works within the Web browser (through JavaScript and the DOM) to render the Web application and handle any requests that the customer might have of the Web server. The beauty of it is this: because the AJAX engine is handling the requests, it can hold most information in the engine itself, while allowing the interaction with the application and the customer to happen asynchronously and independently of any interaction with the server.
Asynchronous:
This is the key. In standard Web applications, the interaction between the customer and the server is synchronous. This means that one has to happen after the other. If a customer clicks a link, the request is sent to the server, which then sends the results back. With AJAX, the JavaScript that is loaded when the page loads handles most of the basic tasks such as data validation and manipulation, as well as display rendering the AJAX engine handles without a trip to the server. At the same time that it is making display changes for the customer, it is sending data back and forth to the server. But the data transfer is not dependent upon actions of the customer.
AJAX techniques use a combination of the following:
Like DHTML, LAMP and SPA, AJAX is not a technology in itself, but a term that refers to the use of a group of technologies. The "core" and defining element of AJAX is the XMLHttpRequest object, which gives browsers the ability to make dynamic and asynchronous data requests without having to unload and reload a page. Given XMLHttpRequest can eliminate the need for page refreshes, other technologies become more prominently used and highlighted with this development approach.
When XMLHttpRequest is used, extensive use of the DOM, CSS and other JavaScript techniques become more important and are used in conjunction to provide a more-enhanced "single-page" experience. While technically not AJAX themselves, these other technologies are generally lumped in with the term because of their relation to the overall user experience when combined with XMLHttpRequest.
Historically AJAX:
Although the term AJAX was coined in 2005, most of the technologies that enable AJAX started a decade earlier with Microsoft's initiatives in developing Remote Scripting. Netscape Evangelism published an article in 2003 referred as Inner-Browsing presenting the paradigm shift for Web page navigation and implementation techniques. Techniques for the asynchronous loading of content on an existing Web page without requiring a full reload date back as far as the IFRAME element type (introduced in Internet Explorer 3 in 1996) and the LAYER element type (introduced in Netscape 4 in 1997, abandoned during early development of Mozilla). Both element types had a "src" attribute that could take any external URL, and by loading a page containing JavaScript that manipulated the parent page, AJAX-like effects could be attained. This set of client-side technologies was usually grouped together under the generic term of DHTML. Macromedia's Flash could also, from version 4, load XML and CSV files from a remote server without requiring a browser being refreshed.
Microsoft's Remote Scripting (MSRS), introduced in 1998, acted as a more elegant replacement for these techniques, with data being pulled in by a Java applet with which the client side could communicate using JavaScript. This technique worked on both Internet Explorer version 4 and Netscape Navigator version 4 onwards. Microsoft then created the XMLHttpRequest object in Internet Explorer version 5 and first took advantage of these techniques using XMLHttpRequest in Outlook Web Access supplied with the Microsoft Exchange Server 2000 release.
The Web development community, first collaborating via the microsoft.public.scripting.remote newsgroup and later through blog aggregation, subsequently developed a range of techniques for remote scripting to enable consistent results across different browsers. In 2002, a user-community modification to Microsoft Remote Scripting was made to replace the Java applet with XMLHttpRequest.
Remote Scripting Frameworks such as ARSCIF surfaced in 2003 not long before Microsoft introduced Callbacks in ASP.NET. In addition, the World Wide Web Consortium has several Recommendations that also allow for dynamic communication between a server and user agent, though few of them are well supported. These would include:
I’ve recently begun working on a project with Osmosoft, which I’ll announce Real Soon Now, and have got my hands dirty with TiddlyWiki to the point where I’m now able to make at least some useful functionality. You effectively get an MVC framework for free with TiddlyWiki, so as a power developer, I can see how it could let you build a certain type of app quite rapidly. Even without too much knowledge, you could use it for prototyping quite easily, just by knowing the key extension points. I figured it would be worth capturing my reflections to date.
There’s a lot of documentation around on TiddlyWiki, and also some good support resources in the form of Groups and IRC. What I’d like to see in addition to that is a guide for people writing “verticals” - web apps building on TiddlyWiki, rather than incremental enhancements. And also it would be good to see a cookbook or pattern collection covering the main types of plugins.
The other issue I’ve had, while I’m brain-dumping, is that plugin exceptions are caught at some point, with an error message shown, and not propagated, so they don’t turn up in Firebug. I need to look into this more as I think there are ways to get better diagnostics. I would also like to get a better understanding of the startup and shutdown lifecycle. As explained in my last post, there are some techniques you can use to hook in at certain stages, though no direct support.
I’ll have an initial stab here at the kind of thing I’d like to see in a developer guide, and refine it massively at a time when I’m less of a green Tiddler, maybe on a wiki. I’m really not qualified to say too much at this stage, but I want to capture it while it’s fresh on my mind. Note there’s already a lot of good material along these lines on the TiddlyWiki wiki.
The simplest way to work is directly inside the TiddlyWiki. Locate shadow tiddlers under the “more” tab and edit them. And create new tiddlers, tag them as “systemConfig”, and stick your plugin code inside them. Each time you change it, hit reload. That’s a nice, simple, way to start off.
For serious development, there are better options. (Which I’m about to start learning.)
The way to extend TiddlyWiki is not to take a TiddlyWiki and start hacking the source. You can do anything you want to do via the following techniques:
In addition, you may find you need more than one TiddlyWiki file to build up your web app. You might end up with a separate file for each key functional area. (I haven’t seen this done, but a guide could explain how to pull in plugins and tiddlers from a common place. Possibly building on TiddlyWeb.)
Here’s a list of shadow tiddlers you might want to customise for your app:
Here are some examples of plugin styles:
Here’s a guide to the most important classes ( (More complete guide on TiddlyWiki internals).):
Let’s look at how those classes give our web app a model and view.
First, the model. How is CRUD handled?
Tiddlers are the atomic model unit in TiddlyWiki. You can inspect the contents using tiddler attributes: