Ajax erfordert ein solides Vorwissen sowohl in JavaScript und dem Document Object Model (DOM), als auch in einer serverseitigen Web-Programmiersprache wie PHP, Perl oder Python. XML-, HTML– und CSS-Kenntnisse werden in vielen Fällen ebenfalls benötigt, sowie nicht selten auch Kenntnisse in Datenbank Management Systemen wie etwa MySQL. Und last but not least sind Kenntnisse über Einzelheiten des HTTP-Protokolls von Vorteil. Wirklich eine Menge Know-How also, weshalb die Ajax-Technologie auch eher im Profibereich angesiedelt ist.
Lassen Sie sich dennoch nicht gleich abschrecken. Wenn Sie von den zuvor genannten Sprachen und Technologien wenigstens schon einmal gehört und eine ungefähre Vorstellung davon haben, werden Sie zumindest die prinzipielle Funktionsweise von Ajax verstehen.
Was ist Ajax?
Für Ajax ist es wichtig zu verstehen, wie die HTTP-Kommunikation üblicherweise abläuft. Werfen wir deshalb zunächst einen kurzen Blick darauf, wie eine Webseite zum aufrufenden Browser kommt. Durch Anklicken eines Links, Eintippen einer Web-Adresse oder Auswählen eines Bookmarks sendet der Browser des Benutzers einen sogenannten HTTP-Request los. Das HTTP-Protokoll muss sich nicht darum kümmern, wie die Anfrage zum gemeinten Webserver gelangt. Dies übernimmt das TCP-Protokoll. Der Inhalt eines HTTP-Requests sieht ungefähr so aus:
GET /search/label/Ajax HTTP/1.1
Host: webkompetenz.blogspot.com
Connection: close
Accept-Encoding: gzip
Accept: text/xml,application/xml,application/xhtml+xml,text/html;
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1)
Gecko/20061204 Firefox/2.0.0.1
Sie müssen nicht alles aus dem Beispiel verstehen. Es genügt zu wissen, dass GET ein HTTP-Kommando ist, mit dem der aufrufende Browser nach Daten verlangt. Die Domain, von der er diese Daten verlangt, ist im Beispiel webkompetenz.blogspot.com. Die Web-Pfadadresse, die er innerhalb dieser Domain verlangt, lautet im Beispiel /search/label/Ajax. Daraus ergibt sich folgende vollständige URL-Adresse:
http://webkompetenz.blogspot.com/search/label/Ajax
Das ist die Adresse, die der aufrufende Browser angefordert hat.
In den weiteren Informationen sendet der Browser noch diverse Informationen darüber mit, etwa in welcher Form er Daten akzeptiert, und wer er selber ist (seine eigene Produktidentifizierung).
Der aufgerufene Webserver beantwortet das GET-Kommando mit einem Response-Kommando. Das Response-Kommando besteht in jedem Fall aus einem HTTP-Statuscode sowie einem HTTP-Header, bestehend aus einem oder mehreren Header-Feldern. Was ein Web-Browser, der obige Webadresse angefordert hat, also beispielsweise als Antwort erhält, könnte in etwa so aussehen:
RESPONSE HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Last-Modified: Thu, 29 Mar 2007 13:27:46 GMT Cache-Control: max-age=0 private Etag: "98d95bd1-a138-4c47-a780-3a2bafe45368" Content-Encoding: gzip Date: Thu, 29 Mar 2007 19:48:28 GMT Server: GFE/1.3
Auch das müssen Sie nicht alles verstehen. Die erste Zeile im Beispiel ist der HTTP-Statuscode. Die Nummer 200 bedeutet: alles in Ordnung, angeforderte Daten sind vorhanden, verfügbar und werden gesendet. Die übrigen Angaben sind HTTP-Header-Felder, beispielsweise zum Inhaltstyp der Daten oder zur Datenkompression.
Im Anschluss an dieses Set aus HTTP-Statuscode und HTTP-Header-Feldern folgen in unserem Fall die eigentlichen Nutzdaten, also der HTML-Code der angeforderten Webseite.
HTTP-Kommunikation „zwischendurch“
Kommunikation zwischen Browser und Webserver findet also dann statt, wenn der Browser eine neue URL-Adresse vom Webserver anfordert. Das kann die Primär-URL sein, die ein Anwender durch Anklicken eines Links, Eintippen einer URL-Adresse oder durch ein Bookmark aufruft. Es können aber auch sekundäre URLs sein, etwa URLs von Grafiken oder Flashmovies, die im HTML-Code der aufgerufenen Seite referenziert sind. Sind jedoch alle zu den eigentlich angeforderten Daten gehörenden Datenressourcen angefordert und übertragen, gibt es bis zur nächsten typischen Anwenderaktion (Link klicken, URL-Adresse eintippen, Bookmark aufrufen) keine weitere Kommunikation mehr zwischen Browser und Webserver – es sei denn, Ajax kommt ins Spiel!
Während eine vom Webserver übertragene Webseite im Browser angezeigt wird, kann sich im Browserfenster durchaus einiges tun. Die angezeigte Webseite enthält beispielsweise ein Navigationsmenü, das sich in verschiedene Zustände bringen lässt. Oder es sind Inhalte per Mausklick ein-/ausblendbar. Solche Effekte werden über Scripts gesteuert, die zu den Daten gehören, die mit der angeforderten Webadresse übertragen wurden. Das Script läuft vollständig im Browser ab. Der Browser verfügt über einen entsprechenden Script-Interpreter.
Die übliche Programmiersprache hierfür ist JavaScript. In Verbindung mit dem Document Object Model (DOM), das moderne Browser in ihre Script-Interpreter integriert haben, und mit der Technik der sogenannten Event-Handler ist es möglich, Inhalte einer gerade angezeigten Webseite abhängig von Benutzerereignissen zu manipulieren. So ist es beispielsweise möglich, dass eine Box beim Überfahren mit der Maus optisch hervorgehoben wird, oder dass ein Listenpunkt beim Anklicken um einen erläuternden Text erweitert wird. All das kann JavaScript, und all das passiert im Browser. Es besteht zu diesem Zeitpunkt keine Verbindung zwischen Browser und Webserver.
Mit Ajax erhält JavaScript jedoch eine weitere wichtige Arbeitsschnittstelle: es kann nun auch über HTTP mit einem Webserver kommunizieren, genauso, wie der Browser es selbst tut.
Dadurch wird es möglich, HTTP-Requests an Event-Handler zu binden und über HTTP erhaltene Daten über die DOM-Schnittstelle dynamisch in die bereits angezeigte Webseite zu integrieren!
Das klingt zunächst sehr abstrakt und nicht besonders sensationell. Betrachten wir jedoch ein einfaches praktisches Beispiel:
In einem HTML-Formular für Selbstregistrierungen kann sich ein Benutzer einen Benutzernamen nach Wunsch vergeben. Der Name muss jedoch eindeutig sein. Dazu könnte eine Schaltfläche „Prüfen“ angeboten werden. Wenn der Benutzer darauf klickt, ruft das durch den onclick-Event gestartete JavaScript via Ajax auf dem heimischen Webserver ein PHP-Script auf und übergibt ihm als Parameter den vom Anwender eingegebenen, gewünschten Benutzernamen. Das PHP-Script schaut in einer Datenbank auf dem Server nach, ob der Benutzername schon vorhanden ist. Wenn ja, sendet es FALSE zurück (Benutzername ist leider schon vergeben), wenn nein, TRUE (Benutzername ist noch nicht vergeben, also frei). Das aufrufende JavaScript bastelt aus dieser Information eine Ausgabe wie „Benutzername ist verfügbar“ oder „Benutzername ist leider nicht verfügbar“ und platziert diese über die DOM-Schnittstelle in der Umgebung des Eingabefeldes. Aus Sicht des Anwenders bleibt die aufgerufene Webseite am Bildschirm stehen. Das JavaScript tut scheinbar etwas Übliches: ausgelöst durch einen Event, blendet es via DOM-Schnittstelle eine Information ein. Ungewöhnlich ist jedoch, dass diese Information auf einer im Hintergrund abgelaufenen HTTP-Kommunikation zwischen JavaScript und einem Webserver basiert.
Wie dieses kleine Beispiel konkret realisierbar ist, werden wir im Praxisteil unserer Ajax-Einführung erfahren. An dieser Stelle ist zunächst wichtig zu verstehen, dass Ajax die HTTP-Kommunikationsschnittstelle in JavaScript ist, und dass sich dadurch zahllose neue Möglichkeiten eröffnen, um vor allem Webanwendungen für Benutzer attraktiver und schneller zu machen.