Wicket

Roland Förther ist Chief Developer bei der Senacor TechnologiesAG in Nürnberg. Seine Arbeitsschwerpunkte sind u.a. Client-Anwen-dungen in C unter Unix/X11 sowie in Java/Swing, Webanwendun-gen in Java/Struts und Ruby on Rails. Er studierte Informatik an derFriedrich-Alexander-Universität in Erlangen.

Carl-Eric Menzel arbeitet als Senior Developer bei der SenacorTechnologies AG. Er beschäftigt sich dort mit den Themen Middle-ware-Entwicklung im Java-Enterprise-Bereich, Java-Webanwendun-gen sowie Usability. Er studierte Informatik an der FH Furtwangen.

Olaf Siefart ist Chief Developer bei der Senacor Technologies AG,wo er mit J2EE-Applikationen und Client-Architekturen (Weban-wendungen) arbeitet. Er absolvierte sein Studium der Informatik ander Universität Marburg.

Roland Förther · Carl-Eric Menzel · Olaf Siefart

Wicket

Komponentenbasierte Webanwendungen in Java

Roland Förtherrfoerther@wicketbuch.de

Carl-Eric Menzelcmenzel@wicketbuch.de

Olaf Siefartosiefart@wicketbuch.de

Lektorat: René SchönfeldtCopy-Editing: Ursula Zimpfer, HerrenbergSatz: Science & More, www.science-and-more.deHerstellung: Nadine ThieleUmschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: Media-Print Informationstechnologie, Paderborn

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über <http://dnb.ddb.de> abrufbar.

ISBN 978-3-89864-984-1

1. Auflage 2010Copyright © 2010 dpunkt.verlag GmbHRingstraße 19 B69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autoren noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

v

Inhaltsverzeichnis

1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Wicket im Dschungel der Java-Webframeworks . . . . . . . . . . . . . 2

1.1.1 Historische Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Der Weg zu komponentenbasierten Frameworks . . . . . 41.1.3 Wie Webentwicklung wieder Spaß macht . . . . . . . . . . . . 71.1.4 Wicket-Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Warum dieses Buch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Für wen ist das Buch geschrieben? . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Was kann das Buch nicht leisten? . . . . . . . . . . . . . . . . . . . . . . . . . . 131.5 Welche Wicket-Version wird betrachtet? . . . . . . . . . . . . . . . . . . . . 131.6 Codebeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.7 Leseleitfaden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Wicket-Schnellstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1 Ein höfliches Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Entwicklungsumgebung für Wicket-Anwendungen einrichten 18

2.2.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Sag der Welt »Guten Tag« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1 Die Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Die (einzige) Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.3 Start! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4 Web 2.0: Autocomplete mit Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Wicket-Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1 Aufbau einer Wicket-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.1 Front-Controller: WicketFilter . . . . . . . . . . . . . . . . . . . . . . . . 363.1.2 WebApplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.3 Seiten und Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.4 Wicket-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1.5 Verwaltung des Anwendungszustandes . . . . . . . . . . . . . . 42

vi Inhaltsverzeichnis

4 Die Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1 Fachliche Anforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Projekt- und Taskverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 454.1.2 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.3 Rollen- und Rechtekonzept . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Technische Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.1 Die Middleware-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.2 Der Webclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.3 Starten der vorbereiteten Anwendung . . . . . . . . . . . . . . . 50

5 Wicket-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1 Basiskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Ausgabekomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.2 Linkkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.1.3 Formularkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.1.4 Listen und Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.2 Zentrales Seitenlayout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.2.1 Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.2.2 Vererbung auf Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 1175.2.3 Fragmente (Inline-Panels) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.2.4 WebMarkupContainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5.3 Komponenten neu definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215.3.1 Fachlich motivierte Komponenten . . . . . . . . . . . . . . . . . . . 1225.3.2 Technische Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6 Anbindung von Anwendungslogik . . . . . . . . . . . . . . . . . . . . . 1456.1 Schichtenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.2 Aufbauen einer Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6.2.1 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486.3 Dependency Injection in Wicket . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6.3.1 Serialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536.3.2 Spring-Integration in Wicket . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.4 Transaktionssteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.4.1 Transaktionssteuerung mit Spring . . . . . . . . . . . . . . . . . . . 157

7 Wicket im Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.1 Aufbau des Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

7.1.1 Application und Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607.1.2 Trennung von UI-Logik und Design . . . . . . . . . . . . . . . . . . 1667.1.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737.1.4 Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827.1.5 Wicket-Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Inhaltsverzeichnis vii

7.2 Request-Verarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037.2.1 WebRequestCycle und WebRequestCycleProcessor . . . 2037.2.2 IRequestTarget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037.2.3 Request-Verarbeitung Schritt für Schritt . . . . . . . . . . . . . . 204

7.3 Page Map und Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

8 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2158.1 Ajax-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2158.2 Wicket und Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

8.2.1 Ajax-Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2208.2.2 Ajax-Fallback-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 2228.2.3 Validierung mit Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2228.2.4 Eigenes JavaScript einbinden . . . . . . . . . . . . . . . . . . . . . . . . 224

9 Komplexe Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2279.1 TabbedPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2279.2 Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2299.3 Rahmenkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2349.4 Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

9.4.1 DataTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2399.4.2 Inmethod Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

9.5 Auf Wicket basierende Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 2439.5.1 Wicket RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2449.5.2 Wicketopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2459.5.3 Databinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

9.6 Konfiguration über JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

10 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24910.1 Containertests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24910.2 Unit Tests mit WicketTester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

10.2.1 Eine Seite testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25610.2.2 Mit der richtigen Applikation testen . . . . . . . . . . . . . . . . . 261

11 Weiterführende Themen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26511.1 Lokalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

11.1.1 Mehrsprachige Texte mit Resource-Bundles . . . . . . . . . . 26811.1.2 Wege zum Resource-Bundle . . . . . . . . . . . . . . . . . . . . . . . . . 27111.1.3 Jenseits mehrsprachiger Texte . . . . . . . . . . . . . . . . . . . . . . . 27511.1.4 Zielgebiet ermitteln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27611.1.5 Lokalisierung von Model-Attributen . . . . . . . . . . . . . . . . . 279

11.2 Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28111.3 Upload von Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

1

1 Einleitung

Entwicklung und Pflege von Java-Webanwendungen stellen hohe An-sprüche an alle Beteiligten: Webdesigner müssen sich täglich mit denLaunen der Webbrowser bezüglich der Interpretation von HTML, CSSund JavaScript auseinandersetzen. Von den Java-Entwicklern wird er-wartet, dass sie einerseits Java beherrschen, aber andererseits auch fitsind in JavaScript, HTML und mehreren XML-Dialekten. In vielen Pro-jekten muss der Java-Entwickler sogar die Aufgaben des Webdesignsmit übernehmen.

Erschwerend kommt hinzu, dass die Basistechnologien des WorldWide Web – HTTP und HTML – nie für die Umsetzung interaktiverBenutzeranwendungen gedacht waren. Seit Jahren versucht man mitFrameworks aus Open-Source-Initiativen, durch den Java Communi-ty Process sowie über kommerzielle Produkte, die Unzulänglichkeitender Webtechnologien vor dem Entwickler zu verbergen, und versprichtihm stattdessen mächtige und zugleich benutzerfreundliche Program-miermodelle.

Dieses Buch zeigt in der Einleitung, welche Rolle das Open-Source-Webframework Wicket dabei spielt und wie es sich gegenüber Main-streamlösungen positioniert. Wir werden dazu einen Überblick über diewichtigsten Features von Wicket geben.

Wir wollen außerdem erläutern, was uns bewegt hat, zum ThemaWicket ein Buch zu verfassen, und welchen Leserkreis wir damit anspre-chen wollen. Wir werden den Leserkreis in Zielgruppen abhängig vonpersönlichen Vorkenntnissen aufteilen und für jede Zielgruppe einenLeseleitfaden aufzeigen.

Am Ende dieser Einleitung sollte der Leser so viel über das Buchwissen, dass er entscheiden kann, ob sich die weitere Lektüre für ihnlohnt.

2 1 Einleitung

1.1 Wicket im Dschungel derJava-Webframeworks

Kaum ein Thema in der Entwicklung von Java-Webanwendungenwird zurzeit so heiß diskutiert wie die Frage, welches Web-framework die beste Wahl ist. Allein unter der Webadressehttp://java-source.net/open-source/web-frameworks werden über fünf-zig Open-Source-Frameworks aufgelistet, unter denen sich der Ent-wickler nach Belieben bedienen kann. Daneben gibt es auch noch et-liche kommerzielle Alternativen.

Warum wird so viel Energie in die Entwicklung von Webframe-works gesteckt? Gibt es keine einzelne Lösung, die leistungsfähig genugist, um die meisten Bedürfnisse zu befriedigen, und die am besten nochstandardisiert ist?

1.1.1 Historische Entwicklung

Betrachten wir die historische Entwicklung der Java-Webtechnologien,um die heutige Situation besser verstehen zu können.

Schon lange bevor die erste Version der Java-Enterprise-PlattformDie Servlet-API

definiert war, hatte Sun mit der Einführung der Servlet-API 1.0 imJahre 1997 den Weg zur Entwicklung von dynamischen Webinhal-ten in Java bereitet. Das Servlet-Prinzip ist leicht zu verstehen, wennman sich ein wenig mit den Grundlagen des HTTP-Protokolls aus-einandergesetzt hat: Anfragen von Clients werden von einer Servlet-Engine entgegengenommen. Jede HTTP-Anfrage wird in ein Java-Objekt vom Typ HttpServletRequest verpackt und über einen URL-Abbildungsmechanismus an ein Servlet delegiert. Dabei wird die Me-thode service(...) einer HttpServlet-Instanz aufgerufen. Das Servletführt serverseitige Logik durch und schreibt die Clientantwort (meistin HTML) in das Containerobjekt vom Typ HttpServletResponse. DieServlet-Engine erzeugt aus dem Antwortcontainer die HTTP-Antwortund liefert sie an den Client zurück.

Auch wenn das Programmiermodell eingängig ist, erregte es erstgrößere Aufmerksamkeit, nachdem Sun zwei Jahre später (1999) dieServlet-Spezifikation 2.1 veröffentlichte und im gleichen Zug mit Ja-JavaServer Pages

vaServer Pages (JSP) eine Technologie einführte, mit deren Hilfe manHTML-Seiten auf Basis von Vorlagen erzeugen konnte. Man hatte of-fensichtlich erkannt, dass die Generierung von Markup in Java wederzur Übersichtlichkeit noch zur Wartbarkeit des Codes beitrug. JavaSer-ver Pages erlauben zur Erzeugung einer Seite die Vermischung von re-gulärem, statischem HTML mit dynamisch generierten Inhalten durch

1.1 Wicket im Dschungel der Java-Webframeworks 3

Java-Code. Mit anderen Worten: Über JavaServer Pages erreicht manim Gegensatz zu Servlets eine Trennung von Darstellung und Inhalt.

Jetzt standen mit Servlets und JSP gleich zwei Ansätze zur Erstel-lung von Anwendungsseiten bereit. Sun hatte sich bereits in Vorab-versionen der JSP-Spezifikation 1.0 darüber Gedanken gemacht, wiedie Rollenverteilung zwischen diesen Technologien aussehen kann. EinVorschlag, den sie Model 2 nannten, ist bis heute Grundlage vieler Web-frameworks (siehe Abbildung 1-1). Die Idee ist, beide Ansätze so in Die MVC-Variante

Model 2die Request-Verarbeitung einzubeziehen, dass jeder für sich seine Stär-ken ausspielen kann. Die Stärke von Servlets liegt klar in der Ausfüh-rung Businesslogik-lastiger Aufgaben. JSP-Seiten dagegen eignen sicham besten für das Rendern von Anwendungsseiten.

Abb. 1-1Model 2 zurStrukturierung derAnwendung

Eine ausführliche Diskussion des Model-2-Anwendungsmusterskann in Abschnitt A.3.3 nachgelesen werden.

Zu Model 2 gesellte sich mit Front-Controller1 bald ein wei- Front-Controller

teres Architekturmuster, das dabei helfen sollte, technisch motivierteController-Logik und die Einbindung Request-übergreifend benötigterDienste zu zentralisieren. Beim Front-Controller-Muster werden alleRequests durch ein einzelnes Servlet – den Front-Controller – geleitet.Das Front-Controller-Servlet bindet zentrale Dienste ein und delegiertan Application-Controller-Instanzen zur Ausführung der anwendungs-spezifischen Logik. Zentrale Dienste decken beispielsweise die Berei-

1http://java.sun.com/blueprints/corej2eepatterns/Patterns/

FrontController.html

4 1 Einleitung

che Internationalisierung, Logging, Authentifizierung oder Autorisie-rung ab.

Front-Controller und Model 2 bilden die Grundlage für viele Web-frameworks. Struts war eines der ersten Frameworks, das diese Archi-Struts – der

Dinosaurier unter den

Webframeworks

tektur nahezu unverändert umgesetzt hat und lange Zeit als De-facto-Standard für die Entwicklung von JEE-Webanwendungen galt. Auchheute findet man in sehr vielen Firmen noch Struts-Anwendungen, dieweiter gepflegt oder migriert werden müssen.

Struts wies als Framework von Anfang an gravierende Desi-gnschwächen auf, die man aber lange Zeit mangels Alternativen inKauf nahm. In Struts2 wurden einige dieser Probleme gelöst, wodurchjetzt z. B. der Front-Controller (der als eine Interceptor-Chain realisiertwird) den eigenen Wünschen entsprechend angepasst werden kann. Je-doch kamen die lange ersehnten Verbesserungen mit Struts2 zu spät,sodass sich zwischenzeitlich Alternativen etablieren konnten, die we-sentlich durchdachter waren. Erwähnenswert hierzu ist beispielsweiseSpring MVC, das sich neben einer sauberen Model-2-Umsetzung auchperfekt in einen Spring-basierten Business-Layer integrieren lässt.

1.1.2 Der Weg zu komponentenbasierten Frameworks

Mit wachsender UI2-Komplexität und Größe einer Webanwendungstellt man fest, dass eine Model-2-Anwendungsarchitektur häufig nichtden erwarteten Mehrwert bietet. Andere Probleme treten dann in denVordergrund, für die Frameworks wie Struts oder Spring MVC kaumLösungshilfen anbieten:

Model-2-Frameworks besitzen gegenüber HTTP und der Servlet-API nur eine dünne Abstraktionsschicht. Unwegsamkeiten des HTTP-Protokolls und Eigenschaften des Browsers als Clientplattform wirkensich bis in den Anwendungscode aus. Hier sind einige prominente Bei-spiele, die eine Behandlung im Anwendungscode erforderlich machen:

■ Die aktuelle Seite wird über die Browserfunktion Page-Reload neuTypische Probleme von

Webanwendungen geladen. Mit dem vorangegangenen Request wurde der Inhalt einesFormulars abgesendet. Ohne zusätzliche Maßnahmen würden dieFormulardaten nochmals gesendet werden – eine unerwünschte Si-tuation, wenn man z. B. mit dem letzten Request eine Banktransak-tion abgeschlossen hat. Vergleichbare Szenarien sind die Browser-Back-Funktion oder das Öffnen eines weiteren Browserfensters.

■ Das manuelle Codieren und Decodieren von URLs ist aufwendig.Fehlerhafte URLs werden oft nur zur Laufzeit erkannt.2User-Interface

1.1 Wicket im Dschungel der Java-Webframeworks 5

■ Hauptaugenmerk fast jeder Webanwendung ist die Verwaltungdes Anwendungszustandes. Der Anwendungszustand gliedert sichin Request-bezogene, benutzerbezogene oder anwendungsglobaleInformationen, für deren Verwaltung die Container HttpRequest,HttpSession und ServletContext durch die Servlet-API bereitge-stellt werden. Diese Container sind wie normale Hashmaps nichttypsicher. Das heißt, Fehler durch falsches Casten werden erstzur Laufzeit aufgedeckt. Die Anwendung ist für den Lebenzyklusder Containerobjekte selbst zuständig. Bezüglich der Sessiongröße,d. h. der Datenmenge in HttpSession, müssen häufig Grenzen ge-setzt werden, wenn man eine große Anzahl paralleler User erlau-ben möchte. Mit zunehmender Größe der Benutzersession erhöhtsich außerdem die zu replizierende Datenmenge beim Betrieb in ei-nem Cluster. Die Verwaltung der Sessiondaten in HttpSession erfor-dert deshalb besondere Aufmerksamkeit durch den Anwendungs-entwickler.

Komplexe Weboberflächen, die nicht nur aus einfachen Formula-ren, Links oder Tabellen bestehen, erfordern unverhältnismäßig hohenEntwicklungsaufwand. Diese Einschätzung teilen vor allem erfahreneDesktop-Anwendungsentwickler, die mit Frameworks wie Swing oderSWT wesentlich effizienter Benutzeroberflächen erstellen können.

Selbst wenn man den hohen Entwicklungsaufwand in Kauf nimmt,sollte man wenigstens erwarten können, dass man das Ergebnis seinerBemühungen wiederverwenden kann – idealerweise als Blackbox ver-packt mit funktionaler Aufrufsematik. Das ist leider nicht der Fall. Ei-ne auf die Granularität von (Web-)Seiten beschränkte Architektur wieModel 2 ist dazu wenig geeignet.

Diese und andere Erkenntnisse haben die Mitglieder des Java Com-munity Process (JCP) dazu bewogen, über den JSR 127 mit JavaServer JavaServer Faces

Faces (JSF) eine komponentenbasierte Architektur und API für Java-Webanwendungen zu definieren, die fortan den Standard in der Ent-wicklung dieser Anwendungsklasse setzen sollte.

Als Kurzfassung lässt sich die JSF-Architektur so beschreiben: UI-Komponenten werden in einem Baum angeordnet. Benutzeraktionenwerden auf serverseitige Ereignisse (Event) abgebildet und von Event-Handlern verarbeitet. Komponenten können sich selbst rendern undihren Zustand bei Bedarf sichern und wiederherstellen. Die Request-Verarbeitung geschieht nach einem fest definierten Phasenmodell, das injeder Phase Einhängepunkte für anwendungsspezifische Erweiterungenbietet.

Auch wenn mit jeder Spezifikation eine Referenzimplementierungvon Sun zur Verfügung gestellt wurde, blieb der Ansturm der Ent-

6 1 Einleitung

wicklergemeinde auf JSF lange hinter den Erwartungen zurück. Selbstheute ist man mit der in der Praxis gelebten JSF-Spezifikation 1.2 alsTeil von JEE 5 noch nicht an einem Punkt angekommen, an dem manvon einer breiten Akzeptanz sprechen kann.

Wie kommt das? Tatsache ist, dass JSF kein One-Stop-Shopping-System aus dem Blickwinkel vieler Projektvorhaben ist. JSF stellt in ers-ter Linie ein Gerüst mit standardisierter API und Erweiterungspunktendar, das in den Projekten um weitere Frameworks angereichert wird,um eine praxisgerechte Plattform zu erhalten. Die Erwartungshaltungder Technologie-Entscheider in Unternehmen gegenüber JSF ist aus un-serer Erfahrung eine andere. Man erhofft sich von JSF eine fertige Lö-sung, die sich nicht nur auf die Bereitstellung eines Komponentenmo-dells konzentriert, sondern viele der täglichen Probleme angeht, so z. B.das Arbeiten in mehreren Fenstern, eine Back-Button-Unterstützungoder Bookmarks von Anwendungsseiten.

JSF soll laut JSR 127 die Entwicklung von Java-Webanwendungendeutlich erleichtern. Komponenten zu schreiben soll ebenso einfachsein, wie bestehende Komponenten wiederzuverwenden. Unserer An-sicht nach trifft es nicht zu, dass Komponenten einfach zu erstellensind. Dagegen spricht schon, dass im Standardfall zahlreiche Artefakteerstellt bzw. gepflegt werden müssen:

■ Komponentenklasse■ HTML-spezifische Komponentenklasse■ Renderer-Klasse■ faces-config.xml■ JSP-Tag-Handler-Klasse■ JSP-Tag-Library-Descriptor

JSF ist klar spezifikationsgetrieben. Das Fähnchen »Standard« wird sohoch gehalten, dass man weitverbreitete Problemfälle aus der Praxisnicht rechtzeitig wahrnimmt und im Standard vernachlässigt. Wir wol-len dies an einem aktuellen Beispiel verdeutlichen. Die Aggregation ei-ner Komponente aus bestehenden Komponenten ist einer der häufigs-ten Gründe, eine Komponente selbst zu schreiben. In JSF muss ein sol-ches Aggregat mühsam in Java-Code erstellt werden. Ein Templating-Mechanismus, der statischen von dynamischem Markup trennt, beidem die zu aggregierenden Komponenten im Markup deklariert wer-den, ist hier besser geeignet. In der Entwickler-Community hat mandas Problem erkannt und bietet z. B. mit Facelets eine Lösung, die dasJSP-basierte View-Handling ersetzt. Bedauerlicherweise ist die Facelet-Technologie kein JSR-Standard.

1.1 Wicket im Dschungel der Java-Webframeworks 7

JSF ist seit JEE5 Bestandteil der Java Enterprise Edition. Verbes-serungen können nur zu den JEE-Release-Zeitpunkten (etwa alle zweiJahre) veröffentlicht werden. Das ist unschön, wenn man bedenkt, dasssich gerade im Bereich der Webtechnologien eine rasante Entwicklungvollzieht.

Auch wenn mit der kürzlich verabschiedeten Spezifikation 2.0 drin-gend gebrauchte Verbesserungen eingeflossen sind, bleibt JSF 2.0 fürviele Anwender weiterhin Zukunftsmusik. Jetzt sind erst einmal dieApplication-Server-Hersteller gefragt, entsprechende Implementierun-gen zu liefern. Selbst dann werden längst nicht alle Anwender von einerälteren JSF-Version umsteigen können, da gerade Enterprise-Kundenoft eine konservative Haltung in Bezug auf ein Upgrade des Applicati-on Server einnehmen.

Alles in allem bietet JSF oft nicht das, was viele davon erwarten.Statt »Ease of Development« und »One-Stop-Shopping« erhält man einBaukastensystem mit großer Lernkurve. Auf der anderen Seite mussman zugestehen, dass durch die Standardisierung einiges in die Toolsund Komponenten rund um JSF investiert wird, wodurch einige seinerSchwächen in der Wahrnehmung abgemildert werden.

1.1.3 Wie Webentwicklung wieder Spaß macht

Abseits des Mainstreams wurde im Jahr 2004 von Jonathan Locke dasOpen-Source-Webframework Wicket initiiert. Jonathans Vision war Wicket als Top-Level-

Apache-Projektes, ein Webframework zu entwickeln, das in der Kategorie der kom-ponentenbasierten Frameworks neue Maßstäbe setzen sollte. WicketsLeitmotiv sollte sein, ein Rahmenwerk bereitzustellen, das intuitivesVorgehen und hohe Effizienz bei der Erstellung von Webanwendun-gen fördert. Bis dato war man von der Umsetzung dieser Vision durchdie Mainstreamlösungen wie Struts und JSF weit entfernt. Wicket fandsehr schnell Beachtung durch die Entwickler-Community. Binnen kur-zer Zeit bildete sich ein schlagkräftiges Kernteam, das bis heute zu-sammen mit einer Vielzahl von Committern das Projekt vorantreibt.Wicket glänzt heute als Top-Level-Projekt unter dem Dach der ApacheSoftware Foundation durch eine äußerst aktive Community.

Wicket unterstützt einerseits das klassische Modell einer Web-anwendung, bei dem die Anwendung aus Webseiten besteht, die mit Gleichzeitige

Unterstützung

klassischer

Webanwendungen und

Rich Internet

Applications

jedem Benutzer-Request neu ausgeliefert werden und mit konventionel-lem HTML auskommen. Gleichzeitig bietet es auch das aktuelle Mo-dell einer Rich Internet Application (RIA), das mithilfe von JavaScriptclientseitig und per Ajax Desktop-ähnliche User-Interfaces ermöglicht.Das Interessante dabei ist aber, dass in Wicket beide Anwendungsar-ten über das gleiche Programmiermodell abgebildet werden und die

8 1 Einleitung

technische Komplexität von Rich Internet Applications komplett durchWicket gekapselt wird.

ImMittelpunkt der Architektur vonWicket steht ein leichtgewichti-ger Komponentenansatz. Wicket orientiert sich dabei grundsätzlich amLeichtgewichtiges

Komponentenmodell

ähnlich zu Swing

Komponentenmodell von Swing, einem Modell zur Entwicklung vonDesktop-Anwendungen in Java. Dies hat zwei entscheidende Vorteile:Man nutzt ein lange bewährtes und praxiserprobtes Modell und kanngleichzeitig Swing-erfahrenen Entwicklern den Einstieg in die Welt derWebanwendungen erleichtern. Wicket schafft es, ein zustandbehaftetesKomponentenmodell aus dem Desktop-Bereich mit den beschränktenMitteln des Web, insbesondere dem HTTP-Protokoll, abzubilden, ohnegleichzeitig den Weg in die native Welt der Webentwicklung zu versper-ren.

Wicket stellt jedem Benutzer der Anwendung virtuellen Anwen-dungsspeicher bereit, dessen Lebenszyklus durch das Framework ver-Virtueller

Anwendungsspeicher waltet wird. Vorbei sind die Zeiten, in denen man Ad-hoc-Objekte inder Websession selbst verwaltete. Zustand wird in Form von Attribu-ten an Komponenten- und Seitenklassen geheftet. Der Anwendungsent-wickler muss sich keine Gedanken mehr darüber machen, ob und wie erDaten in welchen Kontexten der Servlet-API verwaltet, das Frameworknimmt ihm diese Aufgabe ab.

Mit Wicket steht Java im Fokus der Entwicklungstätigkeit. Seitenund Komponenten werden eins zu eins durch Java-Klassen abgebildetJava im Fokus der

Entwicklung und mit Java-Mitteln zueinander in Beziehung gesetzt. Die Anwendungist selbst für die Instanziierung von Komponenten verantwortlich. ImVergleich zu JSF, wo Komponenten über Tags in JSP-Seiten deklariertwerden, hat dieser Ansatz entscheidende Vorteile:

■ Man kann zum einen genau bestimmen, in welcher Phase derRequest-Verarbeitung Komponenten erzeugt werden sollen.

■ Die Komponentenschnittstellen werden nicht auf Umwegen, son-dern über Konstruktoren und Java-Properties der Komponenten-klassen definiert.

■ Schlüsseltechniken der objektorientierten Programmierung wie Ver-erbung und Komposition können voll ausgenutzt werden.

■ Man erfährt bereits zur Compile-Zeit, ob die Komponentenschnitt-stellen korrekt bedient werden (static typing).

Die Fokussierung auf Java hat noch den angenehmen Nebeneffekt, dassman von den Java-Refactoring-Möglichkeiten der Entwicklungsumge-bung profitiert und keine zusätzliche Toolunterstützung wie Eingabe-hilfen oder Validierung für spezielle frameworkrelevante Artefakte be-nötigt.

1.1 Wicket im Dschungel der Java-Webframeworks 9

Mit folgendem Beispiel wollen wir demonstrieren, wie angenehmder puristische Java-Ansatz für den Entwickler ist. Es zeigt, dass cli-entseitiges Verhalten über Java-Klassen gekapselt werden kann, so-dass konventionelle Komponenten durch «Rich»-Eigenschaften ausge-baut werden können, ohne dass der Anwendungsentwickler selbst indie JavaScript-Trickkiste greifen muss.

Abb. 1-2Datumseingabeergänzt umKalender-Widget

Ein Texteingabefeld zur Datumseingabe soll um einen interakti-ven Kalender ergänzt werden (siehe Abbildung 1-2). Das Kalender-Widget ist Bestandteil von Yahoos User Interface Library (YUI), einemJavaScript-Framework, das Widgets zum Entwickeln von Rich InternetApplications bereitstellt:

DateTextField birthday =new DateTextField("birthday", "dd.MM.yyyy");

birthday.add(new DatePicker());

Zur Eingabe des Geburtsdatums wird die KomponenteDateTextField verwendet. Die Klasse DatePicker kapselt die Funktiona-lität des Kalender-Icons mit dem Kalender-Widget als Popup. Die Ka-lenderfunktionalität wird alleine durch die Codezeile birthday.add(newDatePicker()) hinzugefügt. An keiner Stelle im Anwendungscode mussJavaScript eingebunden oder aufgerufen werden.

Über XHTML-Templates werden Layout und statischer Inhalt derAnwendungsseiten definiert. Markierungspunkte in Form von spezi- XHTML-Templates

ohne UI-Logikellen HTML-Attributen weisen das Framework an, zur Laufzeit dortWicket-Komponenten einzufügen. XHTML-Templates beinhalten kei-ne UI-Logik, wie man sie z. B. von JavaServer Pages her kennt, et-wa zum Iterieren von Tabelleninhalten über Custom-Tags und EL-Ausdrücke. In Wicket wird UI-Logik alleine in Java abgebildet. Die Parallele Entwicklung

von Webdesign und

UI-Logik

Templates bleiben trotz der Markierungen für Komponenten reines(X)HTML und können von Webdesignern zu jeder Phase der Entwick-lung mit ihren gewohnten Tools angepasst werden. XHTML-Templates

10 1 Einleitung

unterstützen damit auf natürliche Weise die parallele Entwicklung desWebdesigns und der UI-Logik.

Die Fokussierung auf Java geht einher mit dem Ziel, auch Art undAnzahl sonstiger Artefakte zu minimieren. Nach der Idee der Wicket-Minimierung von

Nicht-Java-Artefakten Framework-Entwickler enthält eine Wicket-Anwendung neben Java imWesentlichen folgende Artefakte:

■ Artefakte der Servlet-Spezifikation, z. B. web.xml■ XHTML-Templates■ CSS-Dateien■ JavaScript-Dateien■ Resource-Bundles

Auf klassische Konfigurationsdateien wie XML- und Property-Dateienzur Anwendungs- und Framework-Parametrierung wird bewusst ver-zichtet. Natürlich sprechen wir hier nicht von Parametern zur Konfi-guration von Businessregeln oder zur Anpassung an die Betriebsumge-bung. Diese haben auch unter Wicket ihre Daseinsberechtigung.

Der Trend weg vom intensiven Gebrauch von Konfigurationsdatei-en wurde mit dem von Ruby on Rails stammenden Paradigma »Con-vention over Configuration« eingeläutet. Dies wurde auch von Wicketübernommen, indem beispielsweise die Verknüpfung von zusammen-gehörigen Ressourcen über Namenskonvention erfolgt. Eine typischeWicket-Seite besteht z. B. aus folgenden Ressourcen:

LoginPage.java // SeitenklasseLoginPage.html // Seitenvorlage (Template)LoginPage.properties // Texte undLoginPage_de.properties // Fehlermeldungen

Solange alle Ressourcen im gleichen Klassenpfad liegen, kann Wicketdiese zueinander in Beziehung setzen.

Ein wunder Punkt vieler Frameworkalternativen ist, dass imFehlerfall unzureichend über die Fehlerursache berichtet wird.Anwendungsfehler, die sich mit der Seite »Error 500 – Internal ServerLeistungsfähige

Fehlerdiagnose Error« bemerkbar machen und den Entwickler zu einer aufwendigenSuche nach der Ursache verleiten, gehören mit Wicket der Vergan-genheit an. Aus Wicket gemeldete Fehler bezeichnen immer Ursachemit Ortsbezug. Abbildung 1-3 zeigt z. B., wie ein Fehler in derSeitenvorlage gemeldet wird.

1.1.4 Wicket-Community

Der Erfolg eines Open-Source-Projekts steht und fällt mit der dahinterstehenden Community bestehend aus den Frameworkentwicklern und

1.2 Warum dieses Buch? 11

Abb. 1-3Hilfe bei derFehlerdiagnose

-anwendern. Die Wicket-Community zeichnet sich durch ein sehr en-gagiertes Kernteam aus ca. 20 Entwicklern aus, von denen etwa dieHälfte seit Projektstart aktiv dabei sind. Zusammen mit den Wicket-Interessierten, die sich in denWicket-Mailinglisten rege beteiligen, kannman von einer sehr aktiven Community sprechen. Das belegt zum Bei-spiel die Statistik des Mailinglisten-Servers http://www.nabble.com/, aufdemWicket regelmäßig unter den Top 10 der aktivstenMailinglisten imBereich der Java-Projekte geführt wird. In der Praxis bedeutet das, dasseine Support-Anfrage in einer der Mailinglisten in der Regel innerhalbweniger Stunden kompetent beantwortet wird.

Die Wicket-Community sorgt für zuverlässige Releasezyklen.Wicket-Major-Releases erscheinen ca. alle zwei Jahre, wobei daraufgeachtet wird, dass eine Migration auf das nächste Release mitvertretbarem Aufwand möglich ist. Die in anderen Open-Source-Webframeworks bisweilen anzutreffende »Innovationswut« beimEntwurf neuer Releases ist hier nicht gegeben. Das spricht auch für dieTragfähigkeit der Wicket-Architektur, die sich im Kern seit dem erstenRelease im Jahr 2005 kaum verändert hat.

1.2 Warum dieses Buch?

Lohnt es sich überhaupt, ein Buch über ein Webframework zu schrei-ben, das nicht zu den Key Playern im Markt zählt? Wird das Interessean Wicket nach einem kurzen Hype nicht wieder schnell abklingen?Wir sind uns sicher, dass Wicket sowohl technisch als auch als Open-

12 1 Einleitung

Source-Projekt mit seiner starken Community überzeugt und gerade imVergleich zu den etablierten Frameworks wie Struts und JSF viele Vor-züge bietet. Leider hat sich in der Vergangenheit des Öfteren gezeigt,dass ein technisch überzeugendes Programmiermodell noch lange keinGarant für die Akzeptanz eines Frameworks ist. Ähnlich verhält es sichmit einer starken Community, wenn diese es nicht schafft, die Visiondes Frameworks zu verbreiten.

Wir bekommen von unseren Kunden immer wieder die gleichenFragen gestellt, wenn wir den Einsatz einer Open-Source-Technologievorschlagen: Gibt es gute Dokumentation zu dem Thema? Gibt es ge-nügend Know-how im Markt? Letztendlich sind es die richtigen Ant-worten auf diese Fragen, die oft mehr wiegen als die technische Brillanzeiner Technologie.

Die als Wiki gepflegte Onlinedokumentation des Wicket-Projekts(http://wicket.apache.org) bietet zwar viel Information für Einsteigerund Experten. Sie ist aber weitestgehend im How-to- bzw. Referenz-stil gehalten, sodass gerade für Einsteiger der »rote Faden« schwer zuerschließen ist.

Genau an dieser Stelle wollen wir mit unserem Buch Abhilfe schaf-fen. Der Einsatz des Webframeworks Wicket soll in Form einer fundier-ten Einführung und praktischen Darstellung vorgestellt werden. Gleich-zeitig verbinden wir damit die Hoffnung, einen Beitrag zur Verbreitungdieses exzellenten Frameworks leisten zu können.

1.3 Für wen ist das Buch geschrieben?

Zum Verständnis dieses Buches ist es wichtig, dass der Leser vertiefteKenntnisse in der objektorientierten Entwicklung mit Java besitzt. In-nerhalb von Java gibt es allerdings Themen, mit denen man auch alserfahrener Java-Entwickler seltener in Berührung kommt. Bei der Ent-wicklung mit Wicket spielen z. B. innere Klassen und anonyme Klasseneine besondere Rolle. Wir werden deshalb auf die entsprechenden Java-Grundlagen bei Bedarf eingehen. Zusätzlich werden fundierte HTML-Kenntnisse und Grundkenntnisse in CSS und JavaScript vorausgesetzt.Zum Erwerb bzw. zur Auffrischung dieser Kenntnisse verweisen wirgerne auf http://de.selfhtml.org/.

Als Hauptzielgruppe sehen wir Webentwickler, die von ihrem ge-wohnten Webframework auf eine leistungsfähigere Alternative umstei-gen wollen. Aus eigener Erfahrung wissen wir, dass viele dieser Ent-Zielgruppe:

Java-Webentwickler wickler durch ihr bisheriges Framework leidgeprüft sind. Wir sprechenhier insbesondere von den Struts-Entwicklern. Auf der anderen Seitewollen wir mit diesem Buch auch diejenigen wachrütteln, die sich hin-

1.4 Was kann das Buch nicht leisten? 13

ter dem Standpunkt verstecken, Webentwicklung sei per se kompliziertund aufwendig3.

Wir wenden uns mit diesem Buch außerdem an Swing- oder SWT4-Entwickler, die eine Plattform für Webanwendungen suchen, mit der sie Zielgruppe: Swing-

oder SWT-Entwicklerschnell und nachhaltig produktiv sein können. Gerade die Verwandt-schaft des Wicket-Programmiermodells mit Swing sollte dieser Leser-gruppe entgegenkommen.

Als dritte Zielgruppe sehen wir Java-Entwickler, die noch keine Er-fahrung in der Entwicklung von Clientanwendungen besitzen. In der Zielgruppe: erfahrene

Java-EntwicklerRegel sind das Entwickler, die zumindest den JEE-Entwicklungsstackziemlich gut kennen, was wir aber nicht zwingend voraussetzen.

1.4 Was kann das Buch nicht leisten?

Mit dem Ziel einer fundierten Einführung in die Programmierung mitWicket ist es leider nicht möglich, alle Aspekte von Wicket abzudecken.Wir beschränken uns auf Themen, von denen wir der Ansicht sind, dasssie die meiste Praxisrelevanz besitzen. Sicher wird der eine oder andereeine Wicket-Komponente vermissen, die wir hier nicht behandeln kön-nen.

Des Weiteren beschränken wir uns beim Thema Backend-Integration auf die Möglichkeiten, die uns das Spring5-Framework hieranbietet. Einen Spring-Service-Layer als Mediator zwischen Frontendund Backend einzusetzen, ist unserer Meinung nach eine weitverbreite-te Option. Dadurch ist es aus Sicht von Wicket nicht mehr relevant, obz. B. Webservices, EJBs oder POJOs angesprochen werden.

1.5 Welche Wicket-Version wird betrachtet?

Die Ausführungen und Codebeispiele beziehen sich auf Wicket in derVersion 1.4, die kurz vor Drucklegung des Buches vom Wicket-Teamfreigegeben wurde. Eine zuweilen anzutreffende Firmenstrategie ist es,dass Frameworks erst dann eingesetzt werden, wenn sie eine gewisseMarktreife erreicht haben. Das zu beurteilen, ist als zukünftiger Frame-workanwender allerdings nicht leicht. Man wartet deshalb vor demEinsatz einfach noch ein paar Minor Releases ab. Sollte das in Ihrem

3Diese Aussage wird vielerorts auch vom Management getragen, wodurchoft der Antrieb in den Entwicklungsabteilungen fehlt, an dieser Situation etwaszu ändern.

4SWT ist ein zu Swing alternatives Widget-Toolkit, das von IBM als Basisfür Eclipse entwickelt wurde.

5http://www.springsource.org/

14 1 Einleitung

Fall zutreffen, so würde sich der Einsatz der Vorgängerversion 1.3 an-bieten.

Die Änderungen zwischen Version 1.3 und 1.4 liegen vor allemin der Unterstützung der Java-Version. Wicket 1.3 kann ab JDK 1.4eingesetzt werden. Mit Wicket 1.4 wird JDK 1.5 zwingend vorausge-setzt, was vor allem daran liegt, dass Generics eingeführt wurden. API-Änderungen zwischen Version 1.3 und 1.4 sind vergleichsweise geringund können mit dem Migrations-Guide unter http://wicket.apache.org/news.html#News-wicket1.4 schnell nachvollzogen werden. Dement-sprechend bietet sich das Buch auch für diejenigen an, die den Einsatzvon Wicket 1.3 planen.

Wicket-Distributionen können auf der Homepage unterDownload

http://wicket.apache.org heruntergeladen werden. In jeder Distri-bution befinden sich sowohl die JAR-Dateien als auch die Sourcen. Imnächsten Kapitel werden wir zeigen, dass durch den Einsatz vonMavendas Herunterladen einer Wicket-Distribution nicht mehr notwendigist, wenn es nur darum geht, die Wicket-Bibliotheken und davonabhängige Bibliotheken im Projekt einzubinden.

Zu jeder Wicket-Distribution gehört auch das Projektwicket-examples

wicket-examples, das eine ganze Reihe von Beispielen für Problemlö-sungen und Anwendungsfälle unter dem Dach einer einzigen Wicket-Anwendung zur Verfügung stellt. Die dort gezeigten Codebeispielemüssen für ein eigenes Problem zwar immer angepasst werden undsind auch nicht durchgehend dokumentiert. Wenn man bei der Arbeitaber gar nicht mehr weiter weiß, kann sich ein Blick in diese Beispielemöglicherweise lohnen. Unter http://www.wicketstuff.org/wicket14/kann man sich die Anwendung wicket-examples live anschauen.

1.6 Codebeispiele

Viele Konzepte und Komponenten lassen sich am besten anhand ei-ner durchgängigen Beispielanwendung erläutern. Eine solche Anwen-dung wurde im Rahmen dieses Buchprojekts entwickelt. Die Kapitel5 – 10 nehmen kontinuierlich auf den Quellcode dieser AnwendungBezug. Er unterliegt der Apache-2-Open-Source-Lizenz6 und kann un-ter http://www.wicketbuch.de heruntergeladen werden.

6http://www.apache.org/licenses/LICENSE-2.0.html

1.7 Leseleitfaden 15

1.7 Leseleitfaden

Das Buch ist so aufgebaut, dass die Lektüre der Kapitel 2 »Wicket-Schnellstart« bis Kapitel 9 »Komplexe Komponenten« in Folge empfoh-len wird. Ab Kapitel 10 »Tests« ist es jederzeit möglich, zwischen denKapiteln zu springen.

Nicht-Java-Webentwicklern wird empfohlen, Anhang A »Besonder-heiten der Webentwicklung« zu lesen, bevor sie mit Kapitel 2 »Wicket-Schnellstart« beginnen.

17

2 Wicket-Schnellstart

Die besten und schönsten Konzepte der Welt sind ohne eine vernünftigeund qualitativ hochwertige Umsetzung nutzlos. Glücklicherweise habendie Wicket-Autoren ihr Konzept exzellent umgesetzt. Und da ein wenigCode dies oft besser zeigen kann als viele Worte, folgt in diesem Kapitelein einfaches Beispiel.

2.1 Ein höfliches Beispiel

Wie es bei der Einführung in neue Frameworks üblich ist, beginnenwir mit einem klassischen Hello-World-Beispiel. Dazu wird eine passen-de Entwicklungsumgebung aufgesetzt, das Beispiel implementiert undauch getestet. Am Ende des Kapitels kommt ein zusätzliches Schman-kerl mit ein wenig Web-2.0-Feeling (inklusive Ajax) hinzu.

Die tiefer gehenden Details werden wir in diesem Kapitel nicht be-handeln, denn es soll hier nur um einen schnellen Start und eine ers-te laufende Mini-Anwendung gehen. In den späteren Kapiteln wirdWicket dann mit all seinen Feinheiten erläutert.

Der erste Teil des Beispiels wird ein einfaches Formular zurNamenseingabe sowie eine Ausgabemöglichkeit haben, um eine per-sonalisierte Begrüßung durch die Anwendung zu ermöglichen (sieheAbb. 2-1).

Das fertige Beispiel wird mitdenken1, sich an die erfolgten Eingabenerinnern und eine Autocomplete-Funktion bieten, wie sie vor einigerZeit von Google gezeigt wurde (siehe Abb. 2-2).

Zunächst erfolgt die Einrichtung der Entwicklungsumgebung, dannwird gezeigt, wie schnell sich mit Wicket eine Anwendung bauen lässt.

1Gute, benutzbare Anwendungen sind höflich und denken mit. Siehe dazudas exzellente Buch »About Face« [2].

18 2 Wicket-Schnellstart

Abb. 2-1Schnellstart: Hallo

Welt!

Abb. 2-2Schnellstart: Hallo

Welt! mit Ajax

2.2 Entwicklungsumgebung fürWicket-Anwendungen einrichten

Über die Entscheidung, eine bestimmte Entwicklungsumgebung odereinen bestimmten Editor2 zu verwenden, lässt sich endlos streiten. Wirgehen davon aus, dass Sie eine bevorzugte Entwicklungsumgebung ha-ben und sich zumindest mit den Grundlagen wie Projekterstellung unddem Einbinden von Libraries auskennen. Eine tiefer gehende Einfüh-rung in eine bestimmte Umgebung würde sowohl den Rahmen diesesBuches sprengen als auch zwangsläufig nur für eine Minderheit der Le-ser relevant sein.

2Die Glaubenskriege zwischen Anhängern von vi und emacs sind bekann-termaßen legendär.

2.2 Entwicklungsumgebung für Wicket-Anwendungen einrichten 19

Stattdessen zeigen wir hier beispielhaft das Aufsetzen eines Projektsfür Eclipse (unter Verwendung des Tomcat3-Servers) sowie eine Pro-jektbeschreibung für Maven (hier wird der Jetty-Server zum Betrieb derAnwendung verwendet).

2.2.1 Eclipse

Eclipse bietet mit Erweiterungen wie dem Web Tools Project (WTP)4

sehr mächtigeWerkzeuge für die Webentwicklung. An dieser Stelle wirdausWTP ein DynamicWeb Project und die Tomcat-Integration verwen-det.

Integration des Tomcats in Eclipse

Für die Integration eines bereits installierten (bzw. ausgepackten) Tom-cats muss nur das Basisverzeichnis der Installation innerhalb derEclipse-Entwicklungsumgebung konfiguriert werden. Dieses wird un-ter Preferences > Server > Runtime Environment bei der Konfigurationeiner entsprechenden Server Runtime angegeben.

Abb. 2-3Eclipse:Tomcat-Integration

3http://tomcat.apache.org4Eclipse WTP: http://eclipse.org/project/wtp.

20 2 Wicket-Schnellstart

Erzeugen des Schnellstart-Projekts

Für das Schnellstart-Projekt kann über einen Eclipse Wizard (New >Other > Web > Dynamic Web Project) ein passendes Eclipse-Projektangelegt werden. Hierbei können alle Defaults übernommen werden,nur der Projektname (quickstart) muss angegeben werden.

Abb. 2-4Eclipse:

Tomcat-Integration

Eine Struktur mit einem Sourceverzeichnis src/main/java/, ei-nem Testverzeichnis /src/test/java/ und einem Applikationsverzeich-nis src/main/webapp/WEB-INF/ hat sich bewährt, letztendlich bleibt dieProjektstruktur aber Ihnen überlassen. Wicket stellt dazu keine festenRegeln auf.

Nachdem in der Server-View eine neue Instanz des Servers erzeugtwurde, kann die Quickstart-Anwendung dieser direkt hinzugefügt wer-

2.2 Entwicklungsumgebung für Wicket-Anwendungen einrichten 21

Abb. 2-5Beispiel-Projektlayout

den, sodass sie beim Start des Servers mit geladen wird. Dabei empfiehltes sich, das Auto-Reload innerhalb des Servers abzuschalten.

Hinzufügen des Projekts zum Server

Abb. 2-6Eclipse:Tomcat-Integration

Alle nachfolgend beschriebenen Abhängigkeiten können nun direktin das WEB-INF/lib-Verzeichnis gelegt werden.

Wicket und seine Abhängigkeiten herunterladen

Zuerst benötigt man die Dateien von Wicket selbst. Laden Sie dazueinfach das aktuelle Release von http://wicket.apache.org/ herunter.Zu Beginn reicht aus der Distribution die Datei wicket-version.jar.

Außerdem werden noch ein paar weitere Bibliotheken gebraucht:Wicket verwendet für das Logging das relativ neue SLF4J-Framework5,

5http://www.slf4j.org/