Vorlesung 5: Ajax

• Held der griechischen Mythologie, rettete zusammen mit einem Helfer des Odysseus den Leichnam des Achill vor Troja
• Verlor im Rededuell gegen Odysseus das Recht auf die Rüstung des Achill und geriet darüber in »Raserei«
• Tötete sich aus Scham, indem er sich in sein Schwert stürzte

Ajax verwenden…

• Das Web bisher: Reload… Reload…
• Benutzer geben Informationen in ein HTML-Formular ein und klicken auf den Submit-Button.
• Der Browser sendet eine Anfrage an den Webserver…
• und dieser beantwortet jede Anfrage, indem er eine völlig neue HTML-Seite zurücksendet.
• Dieser Vorgang wiederholt sich, wiederholt sich, wiederholt sich…

Das sieht jedesmal so aus:

• Die Webseite sendet eine Anfrage mit Hilfe einer JavaScript-Funktion, die die Kommunikation mit dem Server übernimmt.
• Die Antwort des Servers enthält nur die Daten, die die Funktion angefordert hat.
• Das JavaScript in der Webseite baut diese Antwort in die bestehende Seite ein.

• Ajax-Anwendungen sind außerdem asynchron!
• →Das JavaScript sendet Anfragen an den Server
• →Trotzdem kann im Browser weitergearbeitet werden (z.B. Eingaben in Textfenster…)
• →Das JavaScript ändert nur den Teil im Browser, der die Anwendung betrifft
• →Die anderen Eingaben oder Änderungen bleiben bestehen

Das ist eine asynchrone Anwendung:

Das leider nicht!

• führen Anfragen mit Hilfe eines JavaScript-Objekts durch, nicht per Formularversand
• → Abfragebutton ruft eine JavaScript-Funktion auf, keinen Formularversand!

• führen Anfragen mit Hilfe eines JavaScript-Objekts durch
• → Dieses Objekt ist entweder vom Typ »XMLHTTP« (Microsoft) oder vom Typ »XMLHttpRequest« (der Rest der Welt).

• request = new XMLHttpRequest()
• → in realen Anwendungen folgen hierauf eine Unmenge von Browserabfragen, die die korrekte Erzeugung des HTTP-Objekts überwachen.
• request.open("GET", url, true)

• request = new XMLHttpRequest()
• request.open("GET", url, true)
• → statt »GET« kann auch die Methode »POST« verwendet werden
• → url ist die URL des AJAX-Servers (3rd-Party-Server sind aus Sicherheitsgründen nicht erlaubt)
• → wird »false« statt »true« übergeben, wird der Aufruf synchron ausgeführt.

• Die Anfragen und Antworten werden vom Webbrowser durchgeführt und nicht (direkt) vom JavaScript-Code
• → Der Browser leitet die Antwort an das JavaScript weiter.

• Die Anfragen und Antworten werden vom Webbrowser durchgeführt und nicht (direkt) vom JavaScript-Code
• → Der Browser weiß immer, in welchem Bereitschaftsstatus sich eine Anfrage befindet und stellt ihn der JavaScript-Funktion zur Verfügung.

• Wenn der Webbrowser eine Antwort auf die asynchrone Anfrage erhält, wird er den JavaScript-Code zurückrufen
• → Der Browser kann, mit Hilfe der Eigenschaft »onreadystatechange« des Anfrage-Objekts, bei jedem Wechsel des Bereitschaftsstatus eine JavaScript-Funktion ausführen.

• Wenn der Webbrowser eine Antwort auf die asynchrone Anfrage erhält, wird er den JavaScript-Code »zurückrufen«
• → Wenn der Bereitschaftsstatus einer Anfrage == 4 ist, wurde die Anfrage verarbeitet und der Server hat die Bearbeitung abgeschlossen.

• Jetzt wissen wir, was AJAX ist: Asynchronous Javascript And XML

• Mögliche Antwortformate des Servers
• → XML
• → Plain Text
• → Zahlen (Ziffern)
• → JSON

• request.responseXML()
• JavaScripts Core DOM API kann das Parsen der XML-Antwort übernehmen

• Sinnvoll (in der Regel) nur für einfache Anwendungen oder Scraping
• request.responseText() übernimmt den String in eine Variable

• Kommt als Ziffer, d.h. als String
• Muß mit entsprechenden JavaScript-Funktionen umgewandelt werden

• Antwort kommt als JavaScript-Objekt, aufwendiges Parsen entfällt daher
• Gefahr von Cross-Site-Scripting-Attacken (XSS)

• Ajax stellt eigentlich keine besonderen Anforderungen an den Server
• Im einfachsten Falle liefert ein simples PHP-Script die benötigten Antworten
• Für komplexere Anwendungen stehen serverseitige Frameworks, wie z.B. Ruby On Rails zur Verfügung

• (wurde in der letzten Vorlesung über Webservices und APIS ausführlich behandelt)
• SOAP
• XML-RPC
• JSON
• REST (Representational State Transfer)

• Benötigt JavaScript
• Browserweichen
• Navigation (Back-Button)
• Polling-Problem
• Bookmarks

• Latenzzeit
• Barrierefreiheit
• Deep Links
• Zeichenkodierung

• Doch manche Benutzer (und manche Firmen) haben aus Sicherheitsgründen JavaScript immer noch abgeschaltet

• Wie zu frühen DHTML-Zeiten sind wieder Browserweichen und umfangreiche Tests erforderlich, um die unterschiedlichen Implementierungsdetails (spziell DOM) abzufangen.
• Exotische Browser (Safari) fallen dabei oft unter den Tisch

• Da hat sich der Benutzer endlich an den Back-Button gewohnt (der für ihn oft die Undo-Funktion übernimmt) und jetzt funktioniert er nicht mehr.
• Lösung 1: Inline Frames
• Lösung 2 : Mittels Callback-Funktionen den Back-Button abfangen und in der Anwendung entsprechend reagieren (vgl. Dojo-Toolkit)

• Der AJAX-Client muß permanent beim Server nachfragen, ob ein neues Event erzeugt wurde (Polling). Dies erhöht den Traffic und überlastet den Verkehr so arg, daß sich der Browser »verschluckt«.

• Lösung : Warten, bis ein Ereignis oder ein Timeout eintritt
• Neues Problem: Thread beim Server kann nicht freigegeben werden; das kann aber mit Application-Servern, die continuations unterstützen, umgangen werden.

• Bei AJAX-Anwendungen lassen sich nicht mehr unbedingt Bookmarks auf bestimmte Ereignisse setzen
• (Not-) Lösung: #-Anker

• Ohne visuelles Feedback erscheint dem Benutzer eine Ajax-Anwendung oft zäh, da er für das zeitliche Intervall zwischen einer HTTP-Anfrage und der Rückantwort des Servers (Latenzzeit) keine Rückmeldung bekommt.
• Lösung : Fortschrittsbalken (wie bei Sevenload), keine Sanduhr o.ä. (wie bei YouTube)

• Barrierefreie AJAX-Anwendungen sind eigentlich ein Widerspruch in sich, da diese in der Mehrheit für graphische Webbrowser entwickelt wurden.
• → Wer einen barrierefreien Auftritt benötigt, fährt daher oft besser, wenn er entweder auf AJAX verzichtet oder einen zweiten AJAX- und barrierefreien Webauftritt parallel entwickelt (entwickeln läßt)

• Ajax-Anwendungen sind — ähnlich Frames — für Suchmaschinen und für Deep Links schwer zugänglich. Um sie dennoch zu ermöglichen, wurden verschiedene Strategien entwickelt:
• → Lightweight Indexing: An der eigentlichen Webseite werden keine strukturellen Änderungen vorgenommen. Es werden jedoch bereits existierende Elemente, wie beispielsweise Meta-Tags oder Überschriften-Elemente für die Indizierung verwendet.
• → Neues Problem: Google wertet keine Meta-Tags aus.

• → Extra Link Strategy: Zusätzliche Links werden auf der Webseite platziert, denen Suchroboter folgen können, um so den gesamten Webauftritt indizieren zu können. Die zusätzlichen Links müssen nicht sichtbar sein, da sie nur für den Suchroboter einer Suchmaschine gedacht sind.
• Doch Vorsicht! Google reagiert wegen massiven Mißbrauchs durch SEOs mittlerweile »allergisch« auf unsichtbare Links

• → Secondary Site Strategy: Eine zweite Webseite wird parallel entworfen. Diese ist für eine Suchmaschine voll zugänglich. Kann aber sehr aufwendig in Wartung und Pflege werden.

• Alle vorhergenannten Strategien lösen aber nicht das Problem, wie Deep Links von anderen Webseiten auf AJAX-Seiten gelegt werden können. Dies ist ein der Bookmark-Problematik verwandtes Problem, das oft auch nur sehr aufwendig gelöst werden kann.

Nach einem Refresh der Seite ist alles wieder OK

• Viele Ajax-Toolkits versenden XML-Daten, indem sie die in diesem Bereich gängige UTF-8-Zeichenkodierung benutzen. Eine mögliche Ursache für Probleme ist, daß in einem XML-Dokument keine Entity-Referenzen (character entity reference) wie z.B. ö für das Zeichen »ö« verwendet werden können.

• AJAX ist ein faszinierende Technologie, die aber wegen der genannten Probleme nur mit Bedacht und Umsicht eingesetzt werden sollte.

• Ein unvollständige Aufzählung:
• JavaScript-Toolkits
• Serverseitige Frameworks

• Mochi-Toolkit
• Dojo-Toolkit
• Zimbra Ajax Toolkit

• Prototype (und Rico)
• script.aculo.us

• Das Mochi Kit (Open Source, MIT-Licence) ist eine gut dokumentierte Sammlung von JavaScript-Bibliotheken, die bei der Erstellung von Ajax Anwendungen helfen.

• Das Dojo-Toolkit war lange das bekannteste AJAX-Framework (Open Source, Academic Free Licence) – jetzt vermutlich von script.aculo.us überholt worden.
• Dojo ist ein Vertreter der rein clientseitigen Frameworks und hat damit den Vorteil, mit jeder Servertechnologie zu funktionieren.
• Große Widget-Bibliothek.

• Das Zimbra Ajax Toolkit ist eines der umfangreichsten Ajax-Toolkits.
• Für Java-affine Entwickler
• Ursprünglich für die Groupware Zimbra entwickelt.

• Prototype beschränkt sich auf das Wesentliche
• Wird daher meist mit der »Effektbibliothek« Rico kombiniert

• script.aculo.us ist eine weitere Effektbibliothek für AJAX-Anwendungen
• Da sie Bestandteil einiger populärer Frameworks (Ruby on Rails) ist, ist sie mittlerweile ziemlich weit verbreitet

• Ruby On Rails (Ruby)
• TurboGears (Python)
• Django (Python)

• AjaXAC (PHP)
• Google Web Toolkit (Java)
• Pyjama (Python)

• Ruby on Rails ist der Klassiker, an dem sich viele weitere Frameworks orientieren
• Scriptsprache: Ruby
• Kommt mit Prototype und script.aculo.us

• TurboGears ist ein Ruby On Rails in Python

• Django ist ein weiteres Framework für Rapid Development
• Scriptsprache: Python
• Ziemlich beliebt, aber ich weiß nichts über die Eignung für AJAX-Anwendungen

• AjaxAC (Open Source, Apache Licence) verkapselt die gesamte Applikation in eine einzige PHP Klasse
• Diverse Forks und Nebenlinien vorhanden

• Einen ganz anderen Weg geht das Google Web Toolkit (Java):
• Die Entwickler schreiben ihre Frontends in Java unter Verwendung des Google Web Toolkits. Das Framework wandelt die Java-Klassen anschließend in JavaScript und HTML um. Dadurch sollen die Anwendungen in jedem Browser funktionieren.

• Pyjama ist das »Google Web Toolkit« für Pythonistas

• Danke für Ihre Aufmerksamkeit!
• URL: www.cognitiones.de/doku.php/vorlesung_5

• Zurück