Wicket 6

updateAjaxAttributes und IAjaxCallListener

Mit dem neuen Event-Mechanismus wurde auch gleichzeitig der bisher verwendete IAjaxCallDecorator obsolet. Schließlich gibt es kein Skript mehr, das man direkt dekorieren könnte. Da man auch gleichzeitig dem Entwicklern mehr Kontrolle über den Lifecycle eines Ajax-Requests geben wollte, wurde AbstractDefaultAjaxBehavior#updateAjaxAttributes(AjaxRequestAttributes attributes) eingeführt. Durch das Überschreiben dieser Methode erhält man Zugriff auf das AjaxRequestAttributes-Objekt. An diesem können die verschiedensten Parameter einer Ajax-Interaktion konfiguriert werden, z. B.:

  • Request Timeout
  • verwendete HTTP Methode (GET oder POST)
  • Datentyp

Außerdem können IAjaxCallListener (Listing 2) registriert werden. Diese liefern für die jeweiligen Ajax-Lifecycle-Phasen JavaScripte, die vor dem Start der Phase ausgeführt werden. Die Methoden-Namen sind dabei selbsterklärend. Einzig getPrecondition sollte noch erwähnt werden. Das hier erzeugte JavaScript läuft vor jedem Ajax-Call und kann diesen durch die Rückgabe von „false“ verhindern.

Listing 2
public interface IAjaxCallListener
{
	CharSequence getSuccessHandler(Component component);
	CharSequence getFailureHandler(Component component);
	CharSequence getBeforeHandler(Component component);
	CharSequence getBeforeSendHandler(Component component);
	CharSequence getAfterHandler(Component component);
	CharSequence getCompleteHandler(Component component);
	CharSequence getPrecondition(Component component);
}
HeaderItems und Ressource-Abhängigkeiten

Bereits in Wicket 1.5 erfuhr das Ressourcen-Management eine Überarbeitung. Allerdings ergaben sich mit den Änderungen im Ajax-Layer noch einige zusätzliche Anforderungen, die mit dem damaligen API nicht abzubilden waren. Wichtigster Knackpunkt war hier die fehlende Entkopplung von Ressourcen und ihrer Verwendung. Diese erreichte man durch die Einführung der HeaderItems. Statt, wie im Vorgänger, aus einer Vielzahl von render*-Methoden wie z. B. IHeaderResponse#renderJavaScriptReference(ResourceReference reference) die zur richtige herauszusuchen, gibt es in Wicket 6.0 nur noch IHeaderResponse.render(HeaderItem item). Die benötigten HeaderItem-Instanzen werden dabei durch die im Package org.apache.wicket.markup.head neu geschaffenen Factories erzeugt (Listing 3).

Listing 3
...
@Override
public void renderHead(IHeaderResponse response) {
	super.renderHead(response);
	...
	response.render(JavaScriptHeaderItem.forScript("alert('headerscript', 'Jupp, im Header!');", "myScriptID"));
	...
}
...

So war es nun möglich, ein sauberes Dependency Management einzuführen. Bisher musste man sich selbst darum kümmern, alle notwendigen JavaScripte und CSS-Dateien an den richtigen Stellen in den Header einzubinden. Jetzt kann man durch das Überschreiben von ResourceReference#Iterable<? extends HeaderItem> getDependencies() eine Liste von Abhängigkeiten festlegen. Wicket ermittelt vor jedem Render-Durchgang das Abhängigkeiten-Geflecht und bindet alles, was benötigt wird, mit ein.

Ressourcen

Während sich bei der Verwendung von Ressourcen so einiges geändert hat, finden sich bei ihrem eigentlichen API nur zwei Erweiterungen. Die erste ist die neu geschaffene Möglichkeit, mehrere Ressourcen zu einer einzigen zusammenzufassen. ConcatResourceBundleReference fasst mehrere Ressourcen (z. B. JavaScripte) zu einem Paket zusammen. Sie können so „am Stück“ ausgeliefert werden, was die Zahl notwendiger HTTP-Requests und den damit verbundenen Overhead deutlich reduziert.

Die zweite Erweiterung erlaubt es, bestimmte Ressourcen durch andere zu ersetzen. Manchmal möchte man z. B. vorgefertigte Komponenten einsetzen, die aber mit einem veralteten oder fehlerhaften JavaScript ausgeliefert wurden. Bisher musste man hier entweder die Komponente selbst umbauen oder man wendete hässliche Tricks an. Von nun an ist es möglich, diese via WebApplication#addResoourceReplacement zu überschreiben (Listing 4).

Listing 4
@Override
public void init() {
...
	addResourceReplacement(
		BrokenResourceRef.get(),
		FixedResourceRef.get())
	);
...
}

Beim Auflösen der Ressourcen wird Wicket von nun an FixedResourceRef ausliefern, wenn BrokenResourceRef angefordert wurde. Das war’s auch schon.


Themen der folgenden Seiten:

  • Feedback Messages
  • Formulare
  • Servlet 3
  • web.xml vs @Servlet und Co.
  • The Spring Way
  • The JEE6 Way
  • CDI
  • Experimentelles
  • WebSockets
  • Zusammenfassung
Kommentare

Schreibe einen Kommentar

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