Wicket 6

Feedback Messages

Wicket ermöglicht einen sehr flexiblen Umgang mit Fehlermeldungen. Jede Komponente kann solche Feedback Messages erzeugen, die im Weiteren von einem FeedbackPanel dargestellt werden. Leider war es bisher so, dass diese nur innerhalb des Requestzyklus verfügbar waren, in dem sie erzeugt wurden. Das verkomplizierte die Umsetzung bestimmter Validierungsszenarien unnötig, weshalb hier einige wichtige Änderungen durchgeführt wurden.

Im ersten Schritt wurde dafür gesorgt, dass die Meldungen nun in den Meta-Daten der Komponenten abgelegt werden. Sie werden somit zusammen mit ihr serialisiert und sind über mehrere Requests verfügbar.

Im zweiten Schritt erhielten Entwickler die Möglichkeit, via IApplicationSettings#setFeedbackMessageCleanupFilter() einen eigenen IFeedbackMessageFilter (Listing 5) zu registriert. Dieser wird beim Serialisieren der WebSession oder einer Komponente ausgeführt. Gibt der Filter für eine übergebene Nachricht den Wert „true“ zurück, so wird diese als verarbeitet aus der Liste entfernt. Im gegenteiligen Fall bleibt die Nachricht in den Meta-Daten erhalten und kann in einem der darauffolgenden Requests betrachtet werden.

Listing 5
public interface IFeedbackMessageFilter extends IClusterable
{
	boolean accept(FeedbackMessage message);
}

Der einzige Unterschied besteht innerhalb von Formularen: Wird durch Form#validate() die Validierung ausgelöst, so werden alle alten Nachrichten gelöscht.

Formulare

Mit den Formularen erreichen wir auch gleich den letzten Bereich der Wicket-Kern-Änderungen. Hier wurde hauptsächlich etwas API-Kosmetik betrieben, indem die Erzeugung von ValidationErrors vereinfacht wurde. Statt einen Umweg über den Klassennamen des Validators zu gehen, kann er jetzt direkt als Parameter übergeben werden. Somit verkürzt sich die Ermittlung des passenden Default-Keys auf: new ValidationError(validator) . Gleichzeitig wurde mit AbstractRangeValidator#protected ValidationError decorate(ValidationError error, Ivalidatable<V> validatable) die Möglichkeit geschaffen, die erzeugten Fehler zu erweitern oder zu verändern. Allerdings gilt dies nur für RangeValidators. Der genaue Grund hierfür ist mir immer noch nicht ganz klar.

Servlet 3

Mit Servlet 3 leite ich die Liste der optionalen Erweiterungen ein, die aus verschiedenen Gründen nicht Teil der Wicket-Kerndistribution sind. Im Fall von Servlet 3 ist die Erklärung recht einfach: Wicket 6 unterstützt weiterhin Servlet 2.5 als Laufzeitumgebung. Die gleichzeitige Unterstützung von Servlet 3 war somit nur durch das Auslagern der entsprechenden Funktionalitäten in ein neues Wicketstuff-Modul möglich. (Listing 6).

Listing 6
org.wicketstuffwicketstuff-servlet3${wicket.servlet.version}

Servlet 3 (JSR 315) ermöglicht es, Webanwendungen deklarativ durch den Einsatz von Annotationen zu erzeugen (siehe Kasten).

web.xml vs @Servlet und Co.

Die web.xml ist von nun an optional, aber bei Weitem nicht ohne Nutzen. Im Gegenteil, es wäre fatal, komplett darauf verzichten zu müssen. Sie erfüllt auch weiterhin wichtige Aufgaben. So lassen sich über sie diverse Änderungen am Deployment vornehmen, da sie Vorrang vor allen per Annotation getroffenen Einstellungen hat.
So können nachträglich:

  • Filter dazugeschaltet oder entfernt
  • Listener konfiguriert
  • URLs angepasst

werden. Tatsächlich kann sie auch durch das Setzen von
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd


Themen der folgenden Seiten:

  • The Spring Way
  • The JEE6 Way
  • CDI
  • Experimentelles
  • WebSockets
  • Zusammenfassung
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.