Welche Rolle spielt das Modul im Studium?

Das Modul "Web-Engineering" ist eines der möglichen Vertiefungsmodule im Studiengang "Web- und Medieninformatik". Es ist außerdem ein Pflichtmodul für die Weiterbildungszertifikate "Web-Frontend-Programmierer" und "Web-Entwickler". Laut Studienplan sollte es ab dem 5. Semester belegt werden. Das Modul "Web-Programmierung" gilt als inhaltliche Voraussetzung, weil man Grundkenntnisse in HTML, Javascript und am besten auch in XML benötigt. Überraschen könnte, dass auch Grundlagen der Informatik 1 und 2 als Voraussetzung genannt werden. Das liegt daran, dass die Programmierung mit serverseitigen Frameworks wie dem GWT oder dem ZK Framework eine große Rolle spielt, und dafür braucht man solide Java-Kenntnisse. Doch davon später mehr. Empfohlen wird auch, das Modul "Skripsprachen" vorher zu belegen. Dieses Modul bietet eine umfangreichere Einführung in Javascript als "Web-Programmierung". Leider wird es nicht mehr angeboten und laut Studienbüro ist auch kein Ersatz in Sicht. Ich finde das recht ärgerlich, denn beim Durcharbeiten von "Web-Engineering" habe ich oft gemerkt, dass vertiefte JavaScript-Kenntnisse nützlich gewesen wären.

Die Streichung von "Skriptsprachen" wurde mir gegenüber damit begründet, dass viele Studierende sich beklagt hatten, das Modul sei veraltet gewesen. Mir liegt die letzte Auflage des verwendeten Lehrbuches vor. Mein Eindruck ist, dass ich dieses Modul immer noch sehr gerne belegt hätte, und dass es eine sehr gute Vorbereitung für "Web-Engineering" gewesen wäre. Schade, aber nicht zu ändern.

Das Lehrbuch

Der Kurs basiert auf dem Lehrbuch "Web 2.0-Anwendungen mit AJAX" von Jürgen Priemer. Herr Priemer ist auch einer der Autoren des Lehrbuches von "Grundlagen der Informatik 3", wo es unter anderem um GUI-Programmierung in Java am Beispiel von Swing geht. Ich meine, seinen Stil wiedererkannt zu haben. Mit GdI3 kam ich gut zurecht und auch dieses Lehrbuch hat mir wieder gut gefallen. Mit ca. 350 Seiten ist der Umfang leicht unterdurchschnittlich. Das heißt aber nicht, dass man dieses Modul überdurchschnittlich schnell durcharbeiten kann. Die Themenvielfalt ist groß und jeder Themenwechsel geht zu Lasten des Arbeitstempos.

Worum geht es?

Worum geht es nun inhaltlich? Springer hat ja ein verpflichtendes Modul "Web-Anwendungen 2", bei dem es um die Programmierung von Web-Anwendungen mit Java-Server-Pages (JSP) geht. Hier ist das GUI eine HTML-Seite, die von einem Servlet erzeugt wurde. Der Nutzer macht Eingaben in ein Formular und sendet es ab. Das Servlet empfängt einen HTTP-Request, dem Nutzereingaben als Parameter angehängt sind. Das Servlet verarbeitet diese Anfrage, interagiert zu diesem Zweck mit Fachkonzept-Klassen und eventuell auch einer Datenbank und baut eine neue HTML-Datei als Antwort auf die Nutzeranfrage. Diese empfängt der Browser des Nutzers und rendert daraus eine Darstellung, die der Nutzer dann sieht. So weit der klassische Ablauf. Eine grundlegende Beschränkung ist, dass die Serverantwort als neue Seite empfangen wird. Es wird also nach jeder Nutzeranfrage eine komplett neue Seite geladen und gerendert.

Wenn man möchte, dass Web-Anwendungen reaktiver und interaktiver sind, hilft die Technik des XML-HTTP-Requests. Dazu braucht man Code, der clientseitig ausgeführt wird. Der kleinste gemeinsame Nenner auf der Clientseite ist Javascript, das in allen modernen Browsern zur Verfügung steht. Wir haben also clientseitig ein Event-Handling in Javascript, das bestimmte Nutzeraktionen registriert, z.B. dass der Nutzer gerade das Postleitzahlen-Eingabefeld verlassen hat. Der clientseitige Code schickt nun dem Server einen sogenannten XML-HTTP-Request, der z.B. die gerade eingegebene Postleitzahl enthält. Der Server verarbeitet diesen Request, z.B. in dem er bei einem Web-Service den zur Postleitzahl passenden Ort nachschlägt. Nun kommt der entscheidende Punkt: Der Server antwortet nicht mit einer neuen Seite sondern schickt eine Response im XML- oder JSON-Format. Diese Response wird von clientseitigem JavaScript-Code in einer Callback-Funktion ausgewertet. Diese Callback-Funktion verändert oder löscht Elemente der dargestellten Seite oder fügt ihr neue Elemente hinzu. Dies geschieht durch Manipulation des Document Object Models (DOM), dass der Browser auf Grundlage der zuvor empfangenen HTML-Datei erzeugt hat. Zum Beispiel kann die Callback-Funktion nun den Ortsnamen in das Eingabefeld Ort einfügen oder eine Fehlermeldung anzeigen, dass die eingegebene Postleitzahl nicht existiert und den Absenden-Knopf des Formulars deaktivieren, bis der Nutzer diesen Fehler behoben hat.

Der oben beschriebene, grundlegende Prozess steht im Mittelpunkt des Moduls. Durch ihn können Web-Anwendungen reaktiver werden. Seiteninhalte können sich dynamisch ändern, ohne das eine Seite komplett neu geladen werden muss. Web-Anwendungen können mit GUIs ausgestattet werden, die denen von Desktop-Anwendungen ähneln. Sie können komplexere Funktionalität und ein insgesamt flüssigeres Nutzungserlebnis bieten.

Der Preis dafür: Wir müssen nicht nur serverseitigen Code in einer serverseitigen Sprache programmieren (wie z.B. PHP oder Java), sondern auch clientseitigen Code in JavaScript. Wir müssen ein bisschen Hirnschmalz darauf verwenden, die Interaktion zwischen client- und serverseitigem Code hinzubekommen. Und das ganze wird eventuell noch dadurch verkompliziert, dass wir Inhalte von unterschiedlichen Servern oder Web-Services einbinden.

Es gibt nun im wesentlichen drei Möglichkeiten, Web-Anwendungen dieser Art zu implementieren:
1. Wir programmieren den clientseitigen Code von Hand in JavaScript aus. Dann müssen wir uns damit auseinander setzen, dass es Unterschiede zwischen den Browsern gibt. Wir müssen also bedingte Verzweigungen in unseren Code einbauen und Fallbacks schreiben.
2. Wir verwenden ein clientseitiges JavaScript-Framework, dass uns die Arbeit vereinfacht. Bibliotheken verbergen die Unterschiede zwischen den Browsern hinter einheitlichen Funktionsaufrufen und vereinfachen den Umgang mit dem XML-HTTP-Request und der Response. Als Bonus bekommen wir in der Regel Funktionen zur einfachen DOM-Manipulation und fertige GUI-Elemente, zum Bau interaktiver Oberflächen. Im Kurs werden 2 derartige Frameworks vorgestellt: Prototype und das sehr verbreitete JQuery.
3. Wir verwenden ein serverseitiges Framework, das uns erlaubt, den gesamten Code, auch für das was auf dem Client passieren soll, in EINER serverseitigen Sprache zu schreiben. Im Kurs behandelt wird zunächst das Google Web Toolkit (GWT). Hier übersetzt ein Compiler clientseitigen Code von Java nach JavaScript. Auch das ZK Framework wird vorgestellt. Dort programmiert man ebenfalls alles in Java. Der Java-Code wird aber nicht zu JavaScript übersetzt. Stattdessen gibt es zu GUI-Klassen in Java korrespondierende fertige Pendants in JavaScript, die automatisch clientseitig eingebunden werden und mit den serverseitigen Klassen per Remote Procedure Call kommunizieren. Der Vorteil für den Entwickler: Er kann eine (verteilte) Web-Anwendung rein in Java schreiben. Das fühlt sich dann fast an, als würde man eine Desktop-Anwendungen programmieren.

Diese Inhalte bilden den Kern des Moduls. Die verschiedenen Ansätze werden immer wieder am Beispiel eines Heimwerker-Portals demonstriert, dass schrittweise um verschiedene Funktionalitäten erweitert wird. Im Kurs gibt es viele praktische Programmieraufgaben, was natürlich Spaß macht.

Herausforderungen speziell bei diesem Modul

Schwierig ist der häufige Wechsel der Frameworks. Man ist ständig mit neuer Syntax konfrontiert und wird nie richtig sicher im Umgang mit einem Framework. Eine weitere Schwierigkeit ist, dass sich Frameworks schnell weiterentwickeln. Ich hatte zum Teil Mühe, Codebeispiele aus dem Kurs zum Laufen zu bekommen. Oft war hier zusätzliche Zeit für Recherche nötig, um herauszufinden, wie bestimmte Dinge inzwischen gehandhabt werden. Und das, obwohl der Kurs noch gar nicht so alt ist. Das scheint der Preis dafür zu sein, wenn man aktuelle Themen in Module aufnimmt.

Der Umgang mit dieser Schwierigkeit wurde mir erleichtert durch die guten Hilfestellungen und Tipps meines Tutors, der immer wieder Ideen beisteuerte, woran es liegen könnte, dass etwas nicht (mehr) läuft.

Als - durchaus klausurrelevanten - Bonus gibt es noch Kapitel über neue Funktionen in HTML5, wie z.B. das Canvas-Element oder Local Storage. Außerdem gibt es Kapitel über Mashups, also Möglichkeiten, Inhalte aus Web-Diensten in eigene Seiten einzubinden, z.B. Kartendienste, RSS-Feeds, Photo-Dienste, Suchmaschinen und dergleichen. Den Abschluss bildet ein Kapitel über die Google-App-Engine.

Mir hat das Modul viel Spaß gemacht, weil es sehr praktisch war und es viele Einsendeaufgaben gab, bei denen es um Problemlösen ging. Es war schwerpunktmäßig ein Programmiermodul.

Die Präsenzklausur

Was mir im Hinblick auf die Klausur Sorge gemacht hatte: In der Präsenzklausur darf man keinerlei Hilfsmittel verwenden. Ich stellte mir die Frage, wie ich mir die syntaktischen Feinheiten mehrer Frameworks einprägen sollte. Und wie ich vermeiden sollte, diese in der Klausur durcheinander zu bringen.

Diese Sorge war aber unbegründet: Im Gegensatz zum Kurs selbst spielt in der Klausur das Schreiben von Code eine untergeordnete Rolle. Hier geht es vor allem darum, die grundlegenden Abläufe im Zusammenspiel von client- und serverseitigem Code zu verstehen. Auch geht es darum, die Architektur und die konzeptionellen Unterschiede zwischen den verschiedenen Frameworks zu begreifen.

Die Klausur deckt Inhalte aus allen Teilen des Moduls ab. Das ist möglich, weil es auch kleinere Aufgaben mit Wissensfragen gibt, so dass man mit wenig Zeit abchecken kann, ob der Studierende wirklich alle Kapitel durchgearbeitet hat. Das wechselt sich dann wieder ab mit problemlösenden Aufgaben, bei denen man eine eigene intellektuelle Leistung erbringen muss. Eine gut gestellte Klausur, muss ich sagen.

Das heißt leider nicht, dass ich da unbedingt gut abgeschnitten habe. Ein Ergebnis liegt mir noch nicht vor, aber ich weiß inzwischen, dass ich einige "Böcke geschossen" und auch ein paar Sachen verwechselt habe. Die nächsten Wochen werden zeigen, wie stark sich das auf meine Note auswirken wird. Falls sie nicht so gut ausfällt, muss ich mir das aber selbst zuschreiben. Fair gestellt war die Klausur in jedem Fall.

Für wen ist es geeignet?

Web-Engineering ist ein Modul, dass niemand belegen muss. Darum stellt sich am Ende die Frage, wem ich es empfehlen möchte:
- Leute, die praktische Module mit Programmieraufgaben mögen.
- Leute, die Spaß daran haben, in rascher Folge neue Frameworks auszuprobieren.
- Leute, die damit zurechtkommen, auch mal selbst zu recherchieren, weil sich Inhalte schon wieder weiterentwickelt haben.
- Leute, die es nicht darauf anlegen, den Wahlpflichtbereich mit möglichst wenig Arbeitsaufwand hinter sich zu bringen.
- Leute, die auch eine schlechtere Note riskieren möchten, wenn dafür die Modul-Inhalte spannend sind.