Suche
... oder wie aus Minor Major wird

Neues in Wicket 1.5

IRequestMapper

Wicket 1.4 bot bereits ein mächtiges API zur Kontrolle der URL-Erzeugung.
Durch verschiedene RequesCodingStrategies war es möglich, URLs zu verschlüsseln, unterschiedliche Formen von Bookmarkable URLs oder URLs für alle Seiten in einem Package zu erzeugen.
All diese Möglichkeiten existieren auch weiterhin, wurden aber deutlich aufpoliert.
An die Stelle der RequestCodingStrategies sind Implementierungen von IRequestMapper getreten.

Je nach Anforderung kann man nun auf verschiedenste Arten die Erzeugung von URLs manipulieren. Hierzu führt Wicket eine globale Liste von Mappern. Bei einem Request wird jeder Mapper konsultiert und liefert ein Compatibility-Score. Diese Score entscheidet dann über die Reihenfolge, in der die Mapper aufgerufen werden.
Das API wurde durch diese Umstellung leichter verständlich und deutlich konsistenter, wie man an folgendem Beispiel sieht:

Wicket 1.4
protected IRequestCycleProcessor newRequestCycleProcessor() {
        return new WebRequestCycleProcessor(){
                protected IRequestCodingStrategy newRequestCodingStrategy(){
                        return new CryptedUrlWebRequestCodingStrategy(new WebRequestCodingStrategy());
                }
        };   
}
Wicket 1.5
setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this)));
Improved Caching Support

Wicket hatte bisher nur recht eingeschränkte Fähigkeiten zur Kontrolle des Browser-Caches. Um ehrlich zu sein, beschränkte es sich auf eine Methode mit dem Namen setAddLastModifiedTimeToResourceReferenceUrl().
Durch das Setzen dieser Property wurde an Resource-URLs eine Timestamp angehängt. Sobald die entsprechende Datei geändert wurde, änderte sich auch die URL, und der Browser wurde dazu gezwungen, die Resource neu zu laden.

Mit Wicket 1.5 ist es nun möglich, eigene IResourceCachingStrategyies zu implementieren und via getResourceSettings().setCachingStrategy() zu registrieren. Für die gängigen Fälle liefert Wicket bereits entsprechende Implementierungen:

  • QueryStringWithVersionResourceCachingStrategy: Entspricht dem alten Wicket 1.4 Verhalten.
  • NoOpResourceCachingStrategy: Verändert nichts an der URL.
  • FilenameWithVersionResourceCachingStrategy: erweitert die Resource-URL um einen Versionsstring.
Fazit

Es wurde viel aufgeräumt in diesem Release.
Zuvor komplizierte APIs wurden sinnvoll vereinfacht, ohne ihre Mächtigkeit einzubüßen, Deprecations entfernt und wichtige, neue Funktionalitäten hinzugefügt.
Meine persönlichen Favoriten aus der Liste von Änderungen sind das neue Event-System und die Möglichkeit, den Serialisierungslayer auszutauschen.

Konnte man Wicket mit den letzten Releases schon als „erwachsenes“ Framework bezeichnen, so wurde es mit diesem Release deutlich runder und komfortabler in der Nutzung. Was es allerdings braucht, um die Entwickler zu einem Major-Release zu bewegen, ist mir immer noch ein Rätsel.

Jochen Mader ist Senior Entwickler bei der Senacor Technologies AG, wo er sich derzeit hauptsächlich mit der Entwicklung Wicket-basierter Frontends beschäftigt.
Kommentare

Schreibe einen Kommentar

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