Excerpt from Leveraging Drupal: Getting Your Site Done Right

The Basics

Ajax (see www.riaspot.com/articles/entry/What-is-Ajax-) basically exploits an object found in most browsers called XMLHttpRequest (a.k.a. XHR), which allows the browser to carry out an HTTP request to the server without refreshing the page. Using JavaScript, the data returned by the server (which may have nothing to do with XML) may be parsed and then used to modify a DOM element (see www.w3.org/TR/DOM-Level-2-Core/introduction.html) in the served page, also without refreshing the page. This makes a web application behave much more like a regular desktop application, and this is referred to as RIA: Rich Internet Application.

Now, when the data is taken as it is received from the server and plunked into a DOM element (using innerHTML read/write DOM element access, again, supported by major browsers), that is called AHAH: Asynchronous HTML and HTTP. The main thing is that the response from the server cannot be XML or anything other than pure text or valid XHTML or HTML.

This sounds simple but is not so simple, because it involves multiple processes running on multiple hosts in constant communication. This book has already discussed the serving of static and dynamic pages, and understood them. Figure 12-1 shows this in the context of the serving of a static HTML page from the filesystem in the server.

Figure 12-1

Looking at it very simply, the browser sends an HTTP request to the server, like http://litworkshop. lit/cool-haikus/haiku-red.htm; the HTTP server searches for haiku-red.htm in the cool-haikus subdirectory just off the document root; and if it is found, its contents are read and sent back to the browser using the HTTP protocol, with a header and a MIME message so the browser knows what to do with it. The page is rendered — a DOM is instantiated in a browser window and displayed.

With Drupal, the architecture is just a tad more complicated, as you saw in Chapter 7 when Drupal theming was dealt with. Instead of having to draw all the content from files having different MIME types in the server filesystem, the HTTP server talks to Drupal, and Drupal talks to a relational database (MySQL, Postgres, Oracle, etc.) or maybe even to a Web Service or a computer storage cloud like Amazon S3, and assembles the XHTML page complete with optionally compressed associated CSS style sheets and JS scripts. Then all of that is handed over to the HTTP server, which hands it off to the browser making the request, which sees it as if it were a static HTML page.

The reason a lot of stuff like Ajax, AHAH, and JavaScript libraries like jQuery seem so difficult for website developers to get started with is because people tend to lose the notion of where it lives, between the HTTP server, the MySQL database, the PHP code, and browser window, with all kinds of code executing inside different components and servers at the same time. So Figure 12-2 shows the architectural basis, in terms of components, of how a typical Drupal page is rendered: The request is received by the Apache HTTP server process, which figures out via the URL that "this is a job for Drupal." Drupal is booted, and also on the basis of the URL asks the MySQL process for a bunch of data, and in a separate process that was described in Chapter 7, the page is marshaled in its various layers as a stream of bytes sent to the browser, which takes the HTML and goes from there in order to make things happen in the browser window.

Figure 12-2