Guter Wein braucht Zeit. Ein Buch zu schreiben ist vielleicht nicht ganz so zeitaufwendig, aber eben auch nicht mal so schnell gemacht. Ein Buch über Wicket zu schreiben ist aber vermutlich noch eine zusätzliche Herausforderung. Wenn ich vorher gewusst hätte, wie viel Arbeit ich in Praxisbuch Wicket stecken muss, hätte ich es vermutlich nicht angefangen. Aber zum Glück weiß man sowas vorher nicht und so hieß es immer wieder "Zähne zusammen beißen". Der nette Nebeneffekt: ich kenne Wicket jetzt schon sehr genau.

Und das was ich gesehen habe, verdient Respekt. Wicket ist ein sehr gut strukturiertes Softwareprojekt mit sehr guter Dokumentation in den Quelltexten und mit unglaublich vielen Möglichkeiten. Diese unglaubliche Flexibilität hat zwar dazu geführt, dass ich mehr Zeit als erwartet investieren musste, damit das Buch einen sinnvollen Rahmen findet. Aber es ist eben auch diese Flexibilität, die Wicket für so viele Webprojekte qualifiziert.

Warum habe ich das Buch geschrieben? Der Grund ist relativ einfach und indirekt egoistisch: Wenn mehr Leute Wicket benutzen, dann gibt es auch mehr Entwicklungen für Wicket (wie z.B. ein funktionierendes Plugin für Eclipse). Und das fände ich großartig. In dem ich ein Buch schreibe, in dem ich all meine Erfahrungen im Umgang mit Wicket einfließen lasse, beschleunige ich diesen Prozess, weil das Entwickeln mit Wicket wirklich Spass macht. Und wenn der Projektalltag mal nicht so viel Spaß macht, dann ist Wicket ein guter Freund, der Dir den Rücken frei hält.

Ich bin gespannt auf die Reaktionen und das Feedback. Ich danke allen die an mich geglaubt und mich unterstützt haben, und wenn es nur das beheben eines Fehlers war, der mir den Tag gerettet hat.

Michael Mosmann

Wicket 1.4 nähert sich der Fertigstellung. Das ist ein gutes Zeichen, auch wenn ich Wicket 1.4-rc2 bereits längere Zeit ohne Probleme produktiv einsetze. Dieses Jahr wird ein Wicket-Jahr, denn so langsam beschäftigen sich immer mehr Entwickler mit dem Framework. Außerdem erscheinen in diesem Jahr einige Bücher rund um Wicket, so dass man gespannt sein darf, welche Auswirkung aktuelle Literatur zu diesem Thema haben wird.

Für mich steht diese Jahr auch im Zeichen von Scala. Die IDE-Unterstützung verbessert sich zunehmen, so dass man jetzt schon wieder zwischen Eclipse und Netbeans wählen kann. Wenn man dann Scala mit Wicket kombiniert, könnte man bei der Umsetzungsgeschwindigkeit auch Frameworks wie Grails den Platz auch gerade bei einfachen Projekten streitig machen. Das Wicket gerade bei komplexen Projekten punktet hat sich zwar auch noch nicht überall herumgesprochen, aber je mehr Anwendungen mit Wicket realisiert werden, desto schwieriger kann man diese Entwicklung ignorieren.

Damit bleiben für mich zwei Technologien übrig, mit denen man sinnvoll Java-basierte Webanwendungen entwickeln kann: GWT und Wicket. Für alle anderen Frameworks gibt es eigentlich keine Berechtigung, weil es keine guten Gründe mehr gibt, die für deren Einsatz sprechen. Wer andere Meinung ist, kann sich ja in einem Kommentar beschweren.

Am Ende des Jahres werden wir sehen, wie dicht ich dran lag:)

Soeben habe ich eine Migration auf Wicket 1.4-rc2 durchgeführt. Ausschlaggebend für die Migration war die Überarbeitung im Model-Bereich. Typisierte Modelle sind sehr viel handlicher und machen den Code sehr viel lesbarer. Da man die Komponenten ja auch schon generisch angelegt hat, ging diese Information bisher in den Modellen verloren.

Interessante Statistik:

• Anzahl der Java-Dateien im Webprojekt: 376
• Anzahl der Java-Dateien, die angepasst werden mussten: 32
• Zeitaufwand für die Umstellung: 1h,30min

Ich glaube, das Risiko ist gering und der Vorteil ist groß. Meine Empfehlung: Umsteigen.

Es ist ein schöner Moment, wenn man sich von Eigenentwicklungen trennen kann. In meinem Fall ist das ein Webframework für das ich lange keinen Ersatz gefunden habe. Nun habe ich meiner erste vollständig mit Wicket realierte Anwendung fertiggestellt. Die Migration von dem bestehenden Framework war nicht besonders schwer. Allerdings sollte sich die Wicketanwendung aus zwei Gründen genauso verhalten wie die alte Anwendung:

1. Die Entwicklungszeit sollte so gering wie möglich gehalten werden, damit nicht zwei Versionen einer Anwendung zu pflegen sind.
2. Die wichtigsten Seiten sollten an extakt gleicher Stelle auffindbar sein, damit keine Aufwendige Neuindizierung durch Google und andere Suchmaschinen notwendig wird. Der Austausch von Alt und Neu sollte jederzeit rücknehmbar sein, für den Fall, dass es zu Problemen kommt.

Heute ist der große Tag. Gerade habe ich die Anwendung auf den Server geschoben und jetzt wird umgeschalten: www.green-radish.de

In den nächsten Wochen werden dann verschiedene Funktionen hinzukommen, die mit Wicket so viel einfacher zu realisieren sind, dass ich mich schon auf diese Aufgaben freue. Bis dahin freue ich mich auf Feedback.

Michael:)

Wie zeige ich eine Liste von Elementen und die Länge der Liste mit Wicket an, ohne dass ich die Liste zweimal erzeugen muss?

Für die Liste würde man ein LoadableDetachableModel benutzen und in load() das Ergebnis zurückliefern.

final LoadableDetachableModel<List<Something>> modelListe = new LoadableDetachableModel<List<Something>>()
{
  @Override
  protected List<Something> load()
  {
    return Something.asList();
  }
};

Für die Anzahl der Einträge würde ich jetzt auf dieses Modell zurückgreifen:

LoadableDetachableModel<Integer> modelAnzahl = new LoadableDetachableModel<Integer>()
{
  @Override
  protected Integer load()
  {
    return modelListe.getObject().size();
  }

  @Override
  public void detach()
  {
    modelListe.detach();
    super.detach();
  }
};

Wenn modelListe nicht mit einer Wicketkomponente verbunden wäre, würde detach für diese Modell nie aufgerufen und die Liste damit nicht neu erzeugt. Änderungen an der Liste würden sich nicht sofort in der Anzeige wiederspiegeln. Daher muss man in dem Modell, dass mit einer Wicketkomponente verbunden ist auch detach für alle referenzierten Modelle aufrufen. Es gibt eine einfachere Lösung:

public abstract class CascadingLoadableDetachableModel<M,P> extends LoadableDetachableModel<M>
{
  IModel<P> _parent;

  public CascadingLoadableDetachableModel(IModel<P> parent)
  {
    super();
    _parent=parent;
  }

  @Override
  public void detach()
  {
    super.detach();
    _parent.detach();
  }

  @Override
  protected M load()
  {
    return load(_parent.getObject());
  }

  protected abstract M load(P parentModelData);
}

Man übergibt die Modell-Referenz im Konstruktor, bekommt die Modell-Daten automatisch als Methodenparameter und detach wird auch automatisch aufgerufen:

CascadingLoadableDetachableModel<Integer,List<Something>> modelAnzahl = new CascadingLoadableDetachableModel<Integer,List<Something>>()
{
  @Override
  protected Integer load(List<Something> parentModelData)
  {
    return parentModelData.size();
  }
};

Schön kurz.