Apache Wicket

Apache Wicket ist ein komponentenbasiertes Webframework für die Programmiersprache Java. Es ist ein Open-Source-Projekt und heute unter Version 2.0 der Apache-Lizenz verfügbar.

Apache Wicket
Basisdaten
Entwickler	Apache Software Foundation
Erscheinungsjahr	7. Juni 2005[1]
Aktuelle Version	10.5.0[2] (April 2025)
Betriebssystem	plattformübergreifend
Programmier­sprache	Java[3]
Kategorie	Webframework
Lizenz	Apache-Lizenz
wicket.apache.org

Ziel

Wicket verfolgt das Ziel, eine komfortable, leistungsfähige und flexible Möglichkeit zur Erstellung von Webanwendungen für erfahrene Java-Programmierer bereitzustellen, wodurch es ermöglicht werden soll, komplexen Anforderungen gerecht zu werden und eine hohe Produktivität zu erlangen. Durch den komponentenorientierten Ansatz von Wicket ist es sehr leicht möglich, eigene wiederverwendbare Komponenten zu entwickeln.

Wicket zwingt den Programmierer, im Gegensatz zu vielen anderen Frameworks, konsequent objektorientiert zu programmieren. Es wird großer Wert auf Wiederverwendbarkeit gelegt.

Funktionalität

Eigenschaften von Wicket sind:

• Trennung von Logik (Java) und Darstellung (HTML und CSS).
• Jede Komponente kann ihre Daten in ein zugehöriges Datenmodell speichern.
• Automatische Zustandsverwaltung.
• Bis auf web.xml sind keine XML-Konfigurationsdateien nötig. Für die Arbeit mit Wicket sind ausschließlich Java- und (X)HTML-Kenntnisse erforderlich.
• Die Übernahme der Benutzereingaben erfolgt mit Java. Dabei wird durch Java zuerst geprüft, ob eine Eingabe erforderlich ist, anschließend werden die Daten in den entsprechenden Datentyp umgewandelt. Abschließend werden die Daten auf Zulässigkeit (Validierung) geprüft. Diese drei Schritte können komponentenweise oder gemeinsam für ein Web-Formular über ein Fehlerbehandlungssystem abgefangen werden. Werden alle Schritte fehlerfrei durchlaufen, so werden die Daten im Datenmodell abgelegt.
• Ajax ist ohne JavaScript-Kenntnisse möglich. Dafür gibt es einzelne Klassen, die Ajax-Funktionalität bereitstellen.
  • Allen Komponenten kann (auch nachträglich) Ajax-Funktionalität über sogenannte Behaviors hinzugefügt werden. So gibt es unter anderem die Klasse AjaxEventBehavior, zum Reagieren auf ein bestimmtes JavaScript-Ereignis oder die Klasse AbstractSelfUpdatingTimerBehavior, zum automatischen Aktualisieren einzelner Komponenten in bestimmten Zeitintervallen.
• Mit sogenannten Panels kann man Teile einer Seite ändern oder austauschen bzw. die Seite aus verschiedenen Komponenten aufbauen.
• Es ist sehr leicht möglich, wiederverwendbare Komponenten zu entwickeln und diese ggf. mit Ajax-Funktionalität anzureichern.
• Alle erforderlichen Dateien einer Komponente (Java- und HTML-Datei plus ggf. Icon-, CSS- oder JavaScript-Dateien) können zur besseren Wiederverwendbarkeit in eine jar-Datei gepackt werden.
• Sogenannte Ressourcen ermöglichen es, dynamisch generierte Daten einzubinden (z. B. PDF-Daten) oder auf statische Daten (JavaScript-/CSS-Dateien) zuzugreifen.
• Der Aufbau einer URL kann über URLCodingStrategies bestimmt werden.
• Leichte Integrierbarkeit von externen JavaScript-Bibliotheken
• Schrittweise Migration von HTML-Seiten nach Wicket ist möglich.
• Ab Version 1.5 können alle Komponenten sehr einfach Events miteinander austauschen.
• WicketTester ermöglicht den UnitTest einzelner Seiten und auch den Ablauf über mehrere Seiten.

Konzeptionell ist Wicket am ehesten mit Apache Tapestry vergleichbar, konkurriert aber in erster Linie mit JavaServer Faces und Google Web Toolkit.

Geschichte

Die Architektur von Wicket wurde 2004 von Jonathan Locke und Miko Matsumura entworfen und war bis zur Version 1.2 auf sourceforge.org verfügbar. Später wurde das Framework dann unter der Apache-Lizenz als Open-Source-Projekt verfügbar. Eine Gruppe von Programmierern der niederländischen Firma Topicus, die von Eelco Hillenius, Martijn Dashorst und Johan Compagner geleitet wurden, bilden neben einigen anderen bis heute das Kernteam. Wicket ist als Open-Source-Projekt unter der Apache-Lizenz, Version 2.0 verfügbar.

Ab der Version 6.0.0 setzt Wicket zwingend JDK 6 oder höher voraus. Darüber hinaus wird nun von Wicket im Hintergrund jQuery als Ajax-Implementierung verwendet.

Mit Wicket 7.x wird zwingend Java 7 und Servlet (Version 3.x) Container voraus gesetzt.

Seit Wicket 8.x besteht eine vollständige Unterstützung von Java 8.

Lebenszyklus einer Wicket-Komponente

Jede Wicket-Komponente durchläuft einen bestimmten Lebenszyklus. Dabei gibt es drei Hauptphasen:

• Initialisierung
• Rendering
• Removing

Die einzelnen Methoden können jeweils bei Bedarf überschrieben werden.

Phase	Beteiligte Methoden	Beschreibung
Initialisierung	onInitialize	Wird am Anfang des Lebenszyklus ausgeführt. Diese Methode eignet sich als "spezieller Konstruktor" für die Initialisierung aller Komponenten insbesondere bei Klassen, die von WebPage erben. Beim Überschreiben muss die Methode super.onInitialize() als erstes aufgerufen werden. protected void onInitialize() { super.onInitialize(); ..... }
Rendering	onConfigure	Diese Methode wird aufgerufen, bevor das Rendering startet. Insofern ist das die ideale Stelle, um den Status von Komponenten zu steuern, wie z. B. Sichtbarkeit oder Aktivierung. Da die Methoden isVisible oder isEnabled während des Renderns einer Page oder Komponente mehrfach aufgerufen werden, ist es dringend zu empfehlen diese Methoden nicht direkt, sondern stattdessen die Methode onConfigure zu benutzen, um den Status zu steuern. Ist die Sichtbarkeit einer Komponente auf false, so wird die nachfolgende Methode (onBeforeRender) gar nicht mehr aufgerufen.
	onBeforeRender	Diese Methode wird aufgerufen, bevor das Rendering beginnt. Insofern ist es die letzte Chance, die Komponentenhierarchie zu ändern oder Komponenten hinzuzufügen oder zu löschen. Wird diese Methode überschrieben, so muss der Aufruf von super.onBeforeRender() ganz am Schluss erfolgen, da hierbei das Rendering aller nachfolgenden Komponenten angestoßen wird. protected void onBeforeRender() { ..... super.onBeforeRender(); }
	onRender
	onComponentTag	hier kann man beliebige Änderungen am Element (Tag) vornehmen. Es kann sowohl die Art der Komponente getauscht, als auch dessen Style verändert werden. Auch hier darf der Aufruf der Methode der Super-Klasse nicht vergessen werden. protected void onComponentTag(ComponentTag tag) { super.onComponentTag(tag); ..... }
	onComponentTagBody	Diese Methode kann man überschreiben, wenn man den Inhalt einer Komponente verändern will. In Kombination mit der Methode replaceComponentTagBody kann man einen veränderten Inhalt rendern. Will man das Originalverhalten der Komponenten haben, dann muss man die Methode der Super-Klasse aufrufen. public void onComponentTagBody(MarkupStream markupStream, ComponentTag tag) { if(!isEnabled()){ replaceComponentTagBody(markupStream, tag, "(diese Komponente ist deaktiviert)"); } else{ super.onComponentTagBody(markupStream, tag); } }
	onAfterRenderChildren
	onAfterRender
Removing	onRemove	Die Methode kann benutzt werden, um bestimmte Ressourcen, die die Komponente braucht, wieder freizugeben.

Beispiel

Ein einfaches Beispiel besteht aus vier Dateien:

• eine Application-Klasse, die als erstes aufgerufen wird
• eine Java-Datei, die die Seite darstellt
• eine zur Java-Datei zugehörige HTML-Datei
• und die Datei web.xml, den Deployment Descriptor der Web Application für die Konfiguration, welche Klasse die Applications-Klasse ist.

Application-Klasse

Die Application-Klasse dient als zentraler Einstiegspunkt für die Webapplikation. Hier können verschiedene Einstellungen vorgenommen werden, die für die ganze Applikation gültig sind. Unter anderem wird hier die Startseite festgelegt:

package com.myapp.wicket;

import org.apache.wicket.protocol.http.WebApplication;

public class Application extends WebApplication {
    public Class getHomePage() {
        return OnePage.class;
    }
}

Web-Page (Java)

Jede Seite (Page) wird durch eine Java-Klasse und eine zugehörige gleichnamige HTML-Datei repräsentiert. Alle Komponenten der Klasse werden hier definiert. Alle Komponenten, die in der HTML-Datei eine wicket:id haben, werden als Komponenten hinzugefügt.

OnePage.java:

package com.myapp.wicket;

import org.apache.wicket.ajax.AjaxEventBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Button;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.Model;

public class OnePage extends WebPage {

    public OnePage() {
        final Label label = new Label("message", new Model(""));
        label.setOutputMarkupId(true);
        Form form = new Form("form");
        final TextField field = new TextField("field", new Model(""));
        field.setOutputMarkupId(true);
        form.add(field);
        final Button but1 = new Button("button1") {

            @Override
            public void onSubmit() {
                String value = (String) field.getModelObject();
                label.setModelObject("Normal-Request: " + value);
                field.setModelObject("");
                // setResponsePage(AnotherPage.class);
            }
        };
        but1.setOutputMarkupId(true);
        form.add(but1);
        final Button but2 = new Button("button2", new Model("Button deaktivieren ..."));
        but2.add(new AjaxEventBehavior("onclick") {

            @Override
            protected void onEvent(AjaxRequestTarget target) {
                but1.setEnabled(!but1.isEnabled());
                if (but1.isEnabled()) {
                   but2.setModelObject("Button deaktivieren ...");
                } else {
                   but2.setModelObject("Button aktivieren ...");
                }
                target.addComponent(but2);
                target.addComponent(but1);
            }
        });
        form.add(but2);
        add(form);
        add(label);
    }
}

Web-Page (HTML)

Für jede Komponente, die dynamisch verändert werden soll, muss ein Attribut wicket:id angelegt werden.

OnePage.html:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns:wicket>
    <head>
        <title>Echo Application</title>
    </head>
    <body>
        <h1>Echo example</h1>
        <form wicket:id="form">
            <input wicket:id="field" type="text" />
            <input wicket:id="button1" type="submit" value="Button" />
            <input wicket:id="button2" type="button" value="Button deaktivieren ..." />
        </form>
        <p wicket:id="message">Fun Fun Fun</p>
    </body>
</html>

web.xml

Die Application wird lediglich über die folgende web.xml - Datei in den Servlet-Container als Web-Applikation eingebunden:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

    <filter>
        <filter-name>WicketApplication</filter-name>
        <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
        <init-param>
            <param-name>applicationClassName</param-name>
            <param-value>com.myapp.wicket.Application</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>WicketApplication</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>

Kritik

Wicket ist sehr leistungsfähig, wenn es darum geht, komplexe Anforderungen an die Webapplikation zu erfüllen. Geschäftslogik kann vollständig in Java programmiert werden, ohne sich über die Besonderheiten einer Webanwendung Gedanken machen zu müssen. Der Status der Bearbeitung innerhalb einer Session wird jedoch von Wicket serverseitig geführt, wodurch der Entwickler einer Wicketanwendung gezielt das Ressourcenproblem vieler gleichzeitiger Benutzer lösen muss. Im Gegensatz dazu werden oft bei JavaScript-basierten Webframeworks der Status clientseitig gehalten und nur ggf. die Daten vom Server nachgeladen.

Da in Wicket sehr gut JavaScript- oder auch CSS-Frameworks eingebunden werden können, stellt Wicket eine flexible Webentwicklungsplattform dar.

Versionen

Wicket hat im Laufe der Zeit eine große Entwicklung durchlebt.

• ab Wicket 1.4 gibt es Unterstützung für Generische Datentypen. Die letzte Version der 4er-Reihe ist hier Wicket 1.4.23.
• mit Wicket 1.5 wurde die API radikal geändert. Die letzte Version ist hier Wicket 1.5.10.
• mit Wicket 6.x wurde die Wicket-eigene Ajax-Unterstützung durch jQuery ersetzt. Die letzte Version ist Wicket 1.6.20.
• mit Wicket 7.x setzt Wicket zwingend Java 7 und Servlet (Version 3.x) Container voraus.
• seit Wicket 8.0 wird Java 8 vollständig unterstützt. Es wird zusätzlich Servlet 3.1 voraus gesetzt.
• Wicket 9.0 basiert auf Java 11 und nutzt JUnit5. Die interne Klasse Duration wird durch java.time.Duration aus dem JDK ersetzt.
• Wicket 10 basiert auf Java 17, Servlet (Version 5+) und Spring (Framework) 6.

Literatur

• Martijn Dashorst, Eelco Hillenius: Wicket in Action. Manning, Greenwich CT 2008, ISBN 978-1-932394-98-6
• Michael Mosmann: Praxisbuch Wicket. Hanser, 2009, ISBN 978-3-446-41909-4
• Roland Förther, Carl-Eric Menzel, Olaf Siefart: Wicket. Komponentenbasierte Webanwendungen in Java. dpunkt.verlag, 2009, ISBN 978-3-89864-569-0, S. 250 (dpunkt.de [abgerufen am 4. Januar 2010]).
• Igor Vaynberg: Apache Wicket Cookbook. Packt Publishing, 2011, ISBN 978-1-84951-160-5, S. 312 (englisch).

Weblinks

• Wicket-Website
  • Wiki zum Thema Wicket
  • Migrations-Hinweise für Wicket 1.5
  • Migrations-Hinweise für Wicket 6.0
  • Migrations-Hinweise für Wicket 7.0
  • Migrations-Hinweise für Wicket 10
• Website mit Wicket-Demos und Wicket-Komponenten
• Wicket Guide (Dokumentation zu Wicket, die auch Version 6.x abdeckt)
• Vergleich mit Google Web Toolkit (englisch), siehe auch Google Web Toolkit
• Vergleich mit Java Server Faces (englisch), siehe auch JavaServer Faces|