Ajax - Eine pragmatische Einführung in Web 2.0

6 Ajax UI, Teil 1 (S. 82-83)

In den vorangegangenen Kapiteln haben wir sehr ausführlich behandelt, was Ajax ist, was es nicht ist und wo es herkommt. Bisher haben Sie die „asynchronen" und die „XML"- Teile gesehen. In diesem und dem nächsten Kapitel führen wir Sie in die „Javascript"- und die glitzernden UI-Teile der Frameworks ein. Sie werden sehen, wie die CRM-Applikation zu einer vollwertigen Client-Anwendung heranwächst, und lernen dabei einige der aufkommenden Standardmodelle zur Ajaxifizierung von Benutzeroberflächen kennen. Vielleicht am wichtigsten: Wir werden Sie davor warnen, zu sehr zu übertreiben und Ihnen vermitteln, dass Sie den Punkt kennen sollten, an dem „es genug ist".

6.1 Ajax und Javascript für das UI

Dynamic HTML. Sie lesen die Worte und Sie müssen spontan an den Film „Nirvana", die Lewinski-Affaire und Razorfish1 denken. Stimmt. DHTML war so um 1997 herum. Die meisten Leser werden sich jetzt fragen: „Was hat Ajax, was DHTML nicht hatte?" Die Antwort lässt sich nicht in einem einzigen Satz formulieren. Es beginnt schon mit der Ausgereiftheit. Als wir in den 90ern DHTML-Applikationen gebaut haben, ging das nur über Tabellenlayouts. Bis in die späten 90er hatten wir nicht einmal - Tags, Cascading Style Sheets kamen gerade erst auf, und die Sprache selbst war noch nicht gefestigt. Es gab Browserspezifische Erweiterungen für DOM und CSS, und man konnte sich nicht einmal darauf verlassen, dass Browser ihre eigenen Erweiterungen zuverlässig darstellten.

Machen wir einen Zeitsprung in das Jahr 2006. Die Browser sind sich immer noch nicht einig über die beste Darstellung bestimmter Tags, und auch Browser-spezifische Erweiterungen, mit denen man sich herumärgern muss, gibt es noch immer. Aber die Anzahl der Gemeinsamkeiten der modernen Browsern ist in den vergangenen Jahren immens gewach- sen und bietet jetzt eine deutlich größere gemeinsame Basis. Vorbei sind die Zeiten, in denen Sie Browser schon bei einfachen Style-Sheets unterschiedlich behandeln mussten. Wir haben ein wesentlich breiteres Spektrum an akzeptablen UI-Techniken, die überall funktionieren. Diese gemeinsame Basis ohne riesige Teile von Browser-spezifischem Javascript- und CSS-Code macht das Erstellen komplexer Client-Applikationen leichter und überhaupt erst wirklich möglich.

Als wir früher DHTML-Applikationen entwickelt haben, gab es noch keine universelle XMLHttpRequest-Unterstützung. Sicherlich, der IE4 hatte sie als ActiveX-Komponente, aber das kann man wohl schwerlich universell nennen. Wir erinnern uns, wie wir das eingefleischten Windows-Web-Entwicklern beigebracht und dafür komische Blicke geerntet haben. Sogar die Entwickler, die die Komponente hätten einsetzen können, haben sie nicht oft benutzt. Und ohne eine asynchrone eingebettete Verbindung zurück zum Server waren DHTML-Applikationen ohnehin nur Glitzerwerk. Sie brachten nur unwesentliche Verbesserungen in der Bedienbarkeit, und wenn wir wollten, dass sie mit dem Server kommunizierten, standen wir vor Hindernissen.

Denken Sie an die DHTML-Anwendung schlechthin: die allgegenwärtige Baum-Navigation. Es war einfach, DHTML-basierte Bäume zu schreiben. Man brauchte etwas CSS, nahm ein paar onclick-Handler und drückte die Daumen. Der Aufwand war also nicht groß, und wir hatten eine auf- und zuklappbare Baum-Navigation. Was wir nicht hinbekamen, auch wenn wir endlose Stunden investierten, war ein Weg, Teile des Baumes vom Server zu aktualisieren, ohne den gesamten Baum neu zu laden. Also packten wir den Baum in einen eigenen Frame und aktualisierten ihn vollständig, wenn die Applikation es erforderte. Das Ergebnis war gequältes Javascript und alles andere als ein ideales Nutzererleben. Wir sind gerade mal so weit gegangen, uns den iFrame zum Erledigen von Aufgaben im Hintergrund der eigentlichen Operation auszudenken. Wie wir bereits gesehen haben, war der iFrame ein praktischer, allerdings nicht standardisierter Weg, dazu bestimmt, eine zusätzliche Anfrage an den Server zu senden. Javascript kann das scr-Attribut modifizieren, um einen neuen Request auszulösen.

Es scheint – zumindest auf den ersten Blick – alles zu bieten, was XHR auch bietet. Graben Sie etwas tiefer, und Sie werden auf ein paar Probleme stoßen. Erstens verfügen iFrames über keine saubere Methode, um den Status einer Anfrage zu überprüfen; ist sie einmal gesendet, rendert der iFrame entweder die Ergebnisse oder nicht. Zweitens rendert er die Antwort vom Server automatisch. Wenn die Antwort kein HTML ist, muss der iFrame zum Einbinden der Ergebnisse per DOM gesteuert werden. Dies alles funktioniert zwar, aber effektiv ist es wohl kaum, und elegant ist es ganz bestimmt nicht. Die Fähigkeit, UIs zielgerichtet auch im Detail steuern zu können, bekommt ihren eigentlichen Sinn erst, wenn wir gleichzeitig den Abruf der Daten vom Server ebenso zielgerichtet und bis ins Detail hinein steuern.