Wicket: Komponentenbasiert und objektorientiert - das alternative Java-Webframework

Impressum

Jochen Mader

Wicket

ISBN: 978-3-86802-605-4

© 2012 entwickler.press

Ein Imprint der Software & Support Media GmbH

Bibliografische Information Der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen

Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über

http://dnb.ddb.de abrufbar.

Ihr Kontakt zum Verlag und Lektorat:

Software & Support Media GmbH

entwickler.press

Darmstädter Landstr. 108

60598 Frankfurt am Main

Tel.: +49 (0)69 630089-0

Fax: +49 (0)69 930089-89

lektorat@entwickler-press.de

http://www.entwickler-press.de

Lektorat: Sebastian Burkart

Korrektorat: Katharina Klassen

Satz: Dominique Kalbassi

Umschlaggestaltung: Maria Rudi und Laura Kessler

Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

Für Moni, die Liebe meines Lebens.

Vorwort

WICKET

Als Wicket wird im Cricket die aus drei Stäben (Stumps) und zwei Querstäben (Bails) bestehende Holzkonstruktion bezeichnet. An jedem Ende der Pitch befindet sich ein solches Wicket. Der Schlagmann (Batsman) verteidigt es mit seinem Schläger vor dem vom Werfer (Bowler) geworfenen Ball.¹

Als Wicket wird auch ein Webframework bezeichnet, das geschundene Entwicklerseelen wieder an einen höheren Entwickler glauben lässt.

Nach mehreren Jahren Webentwicklung mit verschiedenen Webframeworks von Struts bis Spring MVC verabschiedete ich mich lange Zeit in Richtung Middleware. Durch den Wechsel zu meinem aktuellen Arbeitgeber wurde ich aus meiner heilen, objektorientierten Welt gerissen und landete wieder im Web. Ich muss zugeben, Freude sah anders aus. Der Projektleiter schwärmte von diesem neuen Framework namens Wicket und davon, wie es die Entwicklung von Webanwendungen radikal vereinfacht hätte. Als jemand, bei dem Kämpfe mit Struts mehr als eine Narbe hinterlassen hatten, war ich äußerst, nennen wir es, vorsichtig. Schließlich hatte ich kurz zuvor einen ersten Kontakt mit JSF ...

Wie immer bei einem neuen Framework wurde ich in den ersten Wochen sehr positiv von Wickets Eigenschaften überrascht. Normalerweise folgt auf diese anfängliche Begeisterung eine Phase der Ernüchterung. Jetzt, zweieinhalb Jahre später, warte ich immer noch auf diesen Moment.

Ich möchte nicht behaupten, Wicket wäre einfach. Die Lernkurve kann durchaus frustrierend sein, schließlich wird hier so einiges anders gemacht als bei der Konkurrenz. Wer es allerdings schafft, sich von Konzepten der klassischen Java-Webentwicklung zu lösen, wird seinen Spaß haben. Ich hoffe, mit diesem Buch genau diesen Spaß an andere Entwickler weiterzugeben und zu zeigen, wie sich selbst komplexeste Anforderungen mit Wicket elegant umsetzen lassen.

Danksagung

Zuerst möchte ich mich bei meiner Frau Moni und meinem Sohn Henryk bedanken. Ihre Leidensfähigkeit und Unterstützung in einer sehr stressigen Zeit haben das Buch überhaupt erst möglich gemacht. Des Weiteren möchte ich dem Team von entwickler.press und Jörg Liedl für ihre Unterstützung bei der Entstehung des Buchs danken.

Beinahe hätte ich meinen guten Freund C8H10N4O2 vergessen. Ohne dich wäre der Tag nur halb so lang.

1 http://de.wikipedia.org/wiki/Wicket

2 http://de.wikipedia.org/wiki/Wicket

1 Apache Wicket

Nachdem klar sein dürfte, dass es in diesem Buch nicht um eine exotische Sportart aus dem britischen Commonwealth geht, sondern um ein äußerst beliebtes Open-Source-Webframework, wird es Zeit, das Thema etwas näher zu betrachten.

1.1 Wicket-Steckbrief

Wicket entstand im Jahr 2004 und wurde von Jonathan Locke und Miko Matsumura entworfen. Ziel war es, ein komponentenbasiertes Framework auf Basis des MVC Patterns und starker Integration mit Java-Konzepten zu entwickeln. Man wollte die Webentwicklung näher an den Java-Entwickler heranbringen und sie stärker an objektorientierte Prinzipien binden, als es andere Frameworks bisher taten. Als geistiger Vater von Wicket kann Apache Tapestry angesehen werden, das bereits viele der von Wicket benutzten Features bot. Zusammen mit Tapestry bildet Wicket eine eigene Gruppe von Webframeworks, die sich deutlich von der etablierten Konkurrenz abhebt. Einige von Wickets wichtigen Features sind folgende:

Verzicht auf eine eigene Markup-Sprache

Verzicht auf XML-Konfigurationsdateien

Alle Optionen des Frameworks sind mit sinnvollen Defaults vorbelegt und können im Bedarfsfall über das API geändert werden

Strikte Trennung von Markup und Code

Alle Bereiche des Frameworks sind erweiterbar

Konzentriert sich stark an Konzepten der Rich-Client-Entwicklung à la Eclipse

Man wird in dieser Liste keine wirklich neuen Ideen finden. Wie aber schon bei Ruby on Rails machen hier das gute API und die Integration bereits existierender Konzepte die eigentliche Innovation aus.

1.1.1 Community

Neben der Qualität ist der wichtigste Erfolgsfaktor einer Open-Source-Software die Community. Jedem Wicket-Entwickler kann ich nur empfehlen, sich als Mitglied in der Mailinglist users@wicket.apache.org anzumelden. Die Liste ist sehr aktiv, Fragen werden schnell beantwortet und es besteht ein konstanter Zufluss an neuen Ideen. Wer teilnehmen oder einen Fehler melden möchte, sollte unbedingt die Erzeugung von Quickstart-Applikationen erlernen und eventuelle Probleme dort nachstellen.

1.2 Aufbau des Buchs

Im Moment befindest du dich im ersten von vier Teilen. Zu Beginn werde ich eine Einführung und einen Überblick der Webentwicklung in den letzten Jahren geben. Außerdem werden die wichtigsten Technologien und die mit ihnen verbundenen Herausforderungen vorgestellt. Abschließend gibt es einen kleinen Wicket-Quickstart für die Ungeduldigen. Die weiteren Teile sind folgende:

Aufbau (Kapitel 5 bis 15): Hier werde ich den grundsätzlichen Aufbau von Wicket und seine wichtigsten Konzepte erklären. Die einzelnen Kapitel sind in sich geschlossen und sollen als Referenz für die weiteren Kapitel verwendet werden.

Integration (Kapitel 16 bis 18): Als Unmanaged Framework setzt Wicket kein spezielles Framework für seine Nutzung voraus. In diesem Bereich werden die wichtigsten Verwendungsszenarien vorgestellt und mit Beispielen erklärt.

Applikation (Kapitel 19 bis 26): Dieser Bereich bildet den Abschluss des Buchs. Ziel ist es, eine Applikation, basierend auf den Erkenntnissen aus den vorherigen Bereichen, zu entwickeln. Dabei werden vor allem die verschiedenen von Wicket mitgelieferten Komponenten und ihre Verwendung und Erweiterung erklärt.

Alle Kapitel werden von Codebeispielen begleitet, deren aktuellste Version auf GitHub verfügbar ist:

Codebeispiele für Teil 2 und 3:https://github.com/codepitbull/wicket-buch

Demoapplikation für Teil 4: https://github.com/codepitbull/widone

1.3 Version

Für dieses Buch wird Version 1.5 des Wicket-Frameworks verwendet. Diese Version ist nicht mit 1.4 kompatibel, da sich einige Bereiche des API stark geändert haben und Deprecations entfernt wurden. Alle Beispiele setzen auf der zur Drucklage des Buchs aktuellsten Version auf und werden konstant weitergepflegt.

2 Technologien des Webs

Gemeinhin werden HTML, CSS und JavaScript als die wichtigsten Bausteine von Webanwendungen bezeichnet (früher wurde auch Flash dazugerechnet). Allerdings haben sich Webanwendungen in den letzten zehn Jahren drastisch verändert. Der Fokus hat sich von der Auslieferung statischer Inhalte immer stärker auf dynamische Inhalte und Anwendungen im Stile des klassischen Desktops verschoben. Besonders das Zusammenspiel von AJAX und HTTP wurde immer wichtiger. Im Folgenden werden sie deshalb genauer betrachtet.

2.1 HTTP

Jede Veröffentlichung zum Thema Webframeworks liefert zumindest ein kurzes Kapitel zu HTTP. Das Hyper Text Transfer Protocol ist das wohl am häufigsten missverstandene Protokoll im OSI Model. Wo TCP/IP und UDP als die großen Helden dastehen, liest man über HTTP nur lange Ausführungen über seine Unzulänglichkeiten. Erst in den letzten Jahren wurde vielen Entwicklern bewusst, welch mächtiges und robustes Werkzeug sie da eigentlich haben. RESTful Web Services haben nach Jahrzehnten von SOAP-Irrwegen einen wichtigen Teil zum Umdenken beigetragen. Auf einmal ist es schick, alles am Server als Ressource zu betrachten und allein mit den elementaren CRUD-Operationen (create, retrieve, update, delete) jene Anwendungsfälle abzubilden, die man zuvor mit überspezifizierten SOAP-Services umgesetzt hatte. Was hat das alles nun mit Wicket zu tun?

Wer Webapplikationen entwickeln will, muss die Eigenschaften dieses Protokolls verstehen. Ohne dieses Verständnis werden einem Entwickler Themen wie AJAX für immer ein Buch mit sieben Siegeln bleiben. Man muss nicht erst in die Welt des Web 2.0 gehen, um auf Probleme zu stoßen, die sich nur mit einem guten Verständnis des Protokolls lösen lassen. Wie geht man zum Beispiel mit dem mehrfachen Drücken des Submit-Buttons um? Wozu brauche ich Sessions? Bevor ich diese Fragen beantworte, möchte ich auf die wichtigsten Details von HTTP eingehen. Alles, was man darüber wissen muss, steht in RFC 2616, Kapitel 8. Dort werden die verfügbaren Methoden in ihrer Funktion beschrieben.

Tabelle 2.1: HTTP-Methoden

Zu den Methoden gibt es eine Liste möglicher Antwortcodes.

Tabelle 2.2: HTTP-Antworten

Am Anfang des Kapitels habe ich von CRUD und Ressourcen gesprochen. Beim Betrachten der Methoden wird einem klar, weshalb REST genau auf diese Begriffe abzielt. HTTP ist ein ressourcenorientiertes Protokoll. Alle Operationen haben etwas mit Ressourcen-Manipulation zu tun. Wie hilft uns das bei dem Problem des Mehrfach-Submits?

Ein User drückt ungeduldig auf den Submit-Button oder macht einen Refresh im Browser. Der Browser verhält sich so, wie er soll. Er bekommt die Anweisung, alles nochmal und nochmal zu verschicken. Dabei stößt er jedes Mal die Verarbeitung des Requests an, ohne aber das endgültige Laden der Antwort abzuwarten. Das Ziel der POST-Methode bekommt also immer wieder die gleiche Anfrage geschickt und tut auch genau das, was es soll:

Die Anfrage verarbeiten

Eine Antwort vorbereiten und zurückschicken

Man begann, nach Möglichkeiten zu suchen, dieses Verhalten zu verhindern. Es wurden versteckte Parameter mit Seriennummern eingeführt oder Java-Skripte zum Blockieren des Submit-Buttons entwickelt. Allerdings lässt sich das Problem auf einfachste Art auf Protokollebene lösen. Das Pattern hierfür heißt Post Redirect Get (PRG). Auf einen POST Request sendet der Server eine Antwort mit dem Code 303 (See Other) und leitet den Client auf eine andere Seite weiter. Alle Browser reagieren, wie es der Standard verlangt. Sie folgen dem Redirect und laden die Antwort auf den POST Request via GET von der angegebenen Zieladresse.

Bevor sie nun fortfahren, dieses Buch zu lesen, schlage ich vor, sich mit den Elementaroperationen des HTTP-Protokolls zu beschäftigen. In meinen Augen ist das eine wunderbare Gelegenheit, sich JAX-RS herunterzuladen und damit zu experimentieren.

2.2 AJAX

Ohne AJAX wäre das Web 2.0 nie zu dem Erfolg geworden, der es heute ist. Plötzlich war es möglich, Anwendungen zu schreiben, die deutlich näher an ihren Desktopgegenstücken waren als die Produkte der .COM-Blase. Ganze Office Suites und Mail-Programme wurden zu einer ernsthaften Konkurrenz für den klassischen Desktop. All das ist wieder mal der Verknüpfung bereits existierender Technologien zu verdanken.

Die Bezeichnung Asynchronous JavaScript and XML (AJAX¹) wurde im Jahr 2005 von Jesse James Garrett in seinem Artikel „Ajax: A New Approach to Web Applications" geprägt. Er war zwar nicht der Erfinder der Idee hinter AJAX, aber als Namensgeber wird er wohl für immer in den Geschichtswikis stehen. Tatsächlich wurde die AJAX-Grundidee bereits in den 1990er Jahren von Microsoft entwickelt und sogleich patentiert. Damals wurden IFrames genutzt, um per JavaScript nachgeladene Informationen dynamisch in Webpräsenzen darzustellen. Heute nutzt man statt IFrames die Möglichkeit, per JavaScript den DOM-Baum von HTML-Seiten zu verändern, und statt diverser Eigenimplementierungen kann man heute XMLHttpRequest zur Übertragung der Daten nutzen. Was AJAX