IntroductionIntroduction
As the centerpiece of rich web application development, Ajax brings web interfaces using XHTML and CSS up to desktop application interface standards without the interfaces having to rely on plugins such as Flash or Java. Prior to JavaScript-based server interactions, interfaces had to rely solely on full-page loading, regardless of how one might have hacked a page into appearing otherwise.
Until Ajax development came along (which, incidentally, started in implementation many years before the coining of the term itself), client-side development also had no thread support. Threading, in a nutshell, allows the spawning of new lines of logic, completely independent of those before, adjacent to, or after it. C, Java, Perl, and many other languages have had this support for many years (in some cases) before client-side scripting came along in any fashionable sense. The closest JavaScript had to offer came in the form of the setTimeout and setInterval library functions, which required delayed, seemingly parallel execution rather than the actual spawning of processes. While Ajax still does not provide true threading, it does bring JavaScript one step closer.
0.1 Ajax, the Acronym
The words Asynchronous Javascript And XML make the acronym Ajax. In order to fully understand Ajax in meaning and implementation, you must understand each of its components. Even when using synchronous requests, or using JSON or some other transportation method, knowing the core aspects of Ajax can only help development practices.
Since the initial boom in popularity and resulting hype surrounding Ajax, it can get quite easy to forget what Ajax actually means and what it doesn't. Ajax does exist as an incredibly useful method of communicating with the server directly from JavaScript. It does not mean anything more than that, even if its usage can open up development methods previously unexplored in web application development.
0.1.1 Asynchronous
When requests get submitted to the server, they have no direct impact on any other simultaneous or subsequential requests. In other words, just because a request gets submitted before another request does not in any way ensure that it will receive its response from the server first. Despite the seemingly simplistic concept, asynchronistic behavior in applications often gets ignored, because asynchronicity introduces an entirely new level of complexity to client-side development.
Many Ajax-based web applications use the asynchronous flag of the XMLHttpRequest object solely to handle network errors (sometime without even intending to do so) rather than to keep functionality enabled during a given request. While the direct JavaScript-to-server communication provided by the XMLHttpRequest forms the core of the technology, the asynchronous behavior it also can provide often plays the part of the unsung hero, as it brings a wealth of flexibility and strength to client-side web applications.
0.1.2 JavaScript
JavaScript (based on ECMAScript,1 though possibly vice-versa depending on whom you ask) has many implementations, not only in various web browsers, but also in game development and other applications needing an easy-to-learn scripting language. This book focuses on the implementation of JavaScript in various web browsers. These implementations of JavaScript have a wide variety of incompatibilities, from Mozilla's SpiderMonkey2 to Safari's WebKit to Jscript and more.
1Ecma International, an industry association devoted to standardizing "Information and Communication Technology (ICT) and Consumer Electronics (CE)" (What is Ecma International, http://www.ecma-international.org/memento/index.html), maintains the ECMA-262 standard (http://www.ecma-international.org/publications/standards/Ecma-262.htm) which defines the scripting language of ECMAScript.
2http://developer.mozilla.org/en/docs/SpiderMonkey—The Gecko rendering engine's JavaScript engine written in C is used by Mozilla-based browsers such as Firefox (http://www.mozilla.com/products/firefox), SeaMonkey (http://www.mozilla.org/projects/seamonkey), Camino (http://www.caminobrowser.org), and Epiphany (http://www.gnome.org/projects/epiphany).
Those used to server-side development or OOP (Object-Oriented Programming) may initially get thrown off by JavaScript's prototype-based object model. This, in a very basic sense, means that functions and methods called within a certain object get called in the context of that object. This happens because rather than an instance having an explicit tie to its definition, its prototype merely lays out the basis for its structure and characteristics.
The JavaScript object, XMLHttpRequest (originally an ActiveX control created by Microsoft), provides the key to the entire technology conglomeration now referred to as Ajax. It provides an interface by which JavaScript can send and receive data to and from the server without requiring a full page load. Other methods exist for sending and receiving data, but they each use aspects of HTML and XHTML in ways other than designed, and, as such (while still useful in certain circumstances), they exist only as hacks.
0.1.3 XML
XML stands for eXtensible Markup Language, as defined by the World Wide Web Consortium (W3C; http://w3.org), and provides a very flexible, generic text format. If that seems to be a rather broad description, it should be .XML now uses spanning data storage, communication, definition, description, and presentation. In Ajax, XML refers to data transportation. The XMLHttpRequest object provides another useful bit of functionality along with its HTTP methods: When the server returns XML, the XMLHttpRequest object provides the responseXML attribute, which is a read-only XML document of the response.
Using XML, a very simple response from the server, with two named variables (var1 and var2) each set to string values ("first value" and "second value," respectively), might look like the following:
first value second value
Many Ajax-driven web applications use other formats of transporting data to and from the server, including:
0.2 This Book's Intentions
Now that the technology has progressed into general usage, the Ajax developer community has a need for books covering architecture, tuning, alternative uses of Ajax, and more. Many books and tutorials have provided good introductions, and they can show you several different ways of implementing find-as-you-type, chat widgets, and RSS/ATOM feed readers. Many of the resources out there explain, in great detail, the history of Ajax and its multiple incarnations before today's and the implementation centered on the XMLHttpRequest JavaScript object. See Appendix A, "Resources," at the end of this book for some choice suggestions.
This book, instead, looks at using Ajax to create rich, browser-based interfaces for enterprise-level web applications, taking into account the flexibility, reusability, scalability, and maintainability necessary for such an undertaking. Ajax does not exist in this book as the latest and greatest acronym to hit web development. It instead exists as a tool like any other—extremely useful in some instances and totally wrong in others.
For example, many reference sites would find themselves hard-pressed to use Ajax for anything of particular value to their users. Manuals and other reference materials that have large blocks of text for the user to read might come up with an Ajax reader, allowing a single, scrollable pane that late-loads content as the user scrolls though it. This sounds cool, but it destroys the ability to search the page for a particular word or phrase. It also removes the ability to read something once you've lost your Internet connection. Some reference sites add auto-suggestions to their search fields, but those tend to react too slowly for general usage unless you pre-load the entire dictionary into the browser's memory, potentially wasting a great deal of bandwidth for a feature that only a few people mi...
