Teil 3: Ajax, echte Client-Server-Lösung

Das Beispiel zeigt AJAX im Prinzip, ohne auf Bibliotheken zuzugreifen. Nach dem Prinzip KISS (keep it simple stupid) beweist der Eigenbau, wie einfach gleichsam einzelne Räder die ganze Maschine antreiben. Dieses Vorgehen ist auch empfehlenswert, wenn Sie eine größere, laufende Website an kritischen Stellen um AJAX bereichern möchten. Wer hat dazu einen Programmierstab wie Google?

Das Beispiel ist ein Content-Management-System (CMS), das schon über jede Menge Code verfügt wie zur Aufbereitung, Ausgabe, Cache-Verwaltung etc. In dem CMS soll unser Beispiel-Modul ein Bildarchiv editieren.

Fotojournalisten einer Presseagentur sollen mit diesem CM-Sytem ihre Bilder per Laptop in die Redaktion spielen können. Nach dem Hochspielen ist der nächste Schritt, die Bilder zu editieren und freizugeben. Zu diesem Zeit Zeitpunkt liegen sie bereits auf dem Server, der sie in einer Datenbankverwaltet, Thumbnails sind erstellt. Der Reporter kann jetzt noch seine Bilder kontrollieren, drehen oder löschen, Kommentare hinzufügen etc. Das Bild-Verwaltungs-Modul ist bereits realisiert und sieht im Gesamt-CMS wie imBild unten aus.

Wer mitten auf ein Thumbnail klickt, öffnet ein Edit-Fenster. Ein Klick rechts unten ins Thumbnail markiert das Bild als zu Löschen oder nimmt das Löschungskennzeichen wieder zurück. Das Programm schreibt Änderungen am Bild sofort in die Datenbank. So geht nichts verloren, wenn der Fotograf seinen Laptop zuklappt und nach Hause fährt. Andernfalls würden die aktuellen Bildkommentare stundenlang in der Redaktion fehlen oder eventuell sogar falsche Bilder vorliegen. Daher sollte ein Design so einfach sein, dass unter Stress keine Fehler entstehen. Selbst im Intercity per UMTS aufgerufen, soll das Programm trotz Unterbrechungen durch Funklöcher oder Ablenkungen durch schöne Mitfahrerinnen einfach und zuverlässig funktionieren. Ein Kreuz auf dem Bildschirm muss eindeutig das Bild in der Datenbank zur Löschung markieren.

Also ruft jeder Klick - sei es auf das Lösch-Kennzeichen oder auf den OK-Button - den Webserver auf, der die Daten speichert und die Seite neu aufbaut. Das mag sich für vier oder fünf Thumbnails auf einer Web-Site gut anhören. Was passiert aber bei zwanzig oder fünfzig Bildern - selbst wenn sie im Daumennagel-Format vorliegen? Was passiert, wenn Sie scrollen müssen, weil Ihr zu editierendes Thumbnail unten steht? Das Interface kommt an seine Grenzen! Zudem läuft der Anwender in Warteschleifen in die Gefahr, dass er das falsche Thumbnail per Löschklick markiert, weil sich der Server gerade abmüht, die Seite aufzufrischen. Oder soll der Server mehrere Seiten liefern, wenn sich die Bilder häufen? Hier kann nur noch AJAX den einfachen Einseiten-WYSIWYG Dialog gestalten.

Zunächst löst ältere Technik dieses Aufgabenbündel: Im Browser baut sich im Edit-Fenster eine Tabelle mit einem Formular auf, die unsichtbar bleibt (visibility:hidden). Bei einem Klick in ein Thumbnail wird über Java-Script das Edit-Fenster mit den Werten des aktuellen Bildes gefüllt und oberhalb des Seiteninhalts (zIndex:10) angezeigt. Sie können darin editieren und per OK-Submit die Daten an eine Hilfs-PHP-Prozedur (Listing) übertragen:

So enthält das Fenster das Formular für den erneuten Seiten-Aufruf. Auf dem Server übernimmt die Hilfs-PHP-Prozedur /pix_do.php aus dem Aufruf die Parameter und speichert sie in SESSION-Variablen. Dann wird dieselbe CMS-Seite wieder angezeigt. Das Update der Datenbank geschieht vor der erneuten Anzeige in unserem Bildverwaltungsmodul. Das ist umständlich, aber die Daten sind im Formular und sollen in den PHP-Code des Bildverwaltungsmoduls zurück. Natürlich können Sie keine Serveraktion auslösen, ohne gleichzeitig eine neue Seite aufzubauen.

Dies ginge vielleicht in einem unsichtbaren Frame, doch würden Sie der CMS-Ausgabe ins Handwerk pfuschen. Wie soll die neue technische Lösung mit AJAX aussehen?