Ich bin kürzlich über ein Stück Code gestolpert, der mich zum nachdenken brachte. Um zu illustrieren, welcher Umstand dafür verantwortlich war, benötige ich diesemal am schon Anfang ein paar Zeilen Code. Die folgende Hilfsklasse dient nur dazu, bei dem einzig möglichen Methodenaufruf eine Liste von Daten zu erzeugen: ...

Eine Liste von Ergebnissen aus einer Tabelle in der Datenbank zu laden und über ein Model zur Verfügung zu stellen, ist eine recht einfache Angelegenheit. Wicket sorgt dafür, dass die Liste kein zweites mal geladen wird, nur weil das Model durch eine zweite Komponente dargestellt wird. Wenn man z.B. so triviale Dinge wie die Summe aller angezeigten Einträge ermitteln möchte, empfiehlt es sich, auf die bereits geladenen Daten aus dem Model zurückzugreifen. Für diesen Zweck kann man auf eine spezialisierte Model-Klasse zurückgreifen, die sich darum kümmert, das die detach()-Methode auch für alle referenzierten Modelle aufgerufen wird. Der Ansatz ist recht einfach, aber es geht vielleicht noch ein wenig eleganter. ...

Ich benutze für alle Projekte Maven. Der eine oder andere mag mit Maven auf dem Kriegsfuß stehen (was ich zwar nicht verstehe, aber akzeptiere). Bisher war ich (und an anderer Stelle war es auch nicht notwendig, darüber nachzudenken) für eine saubere Trennung von Code und Resourcen. Das bedeutet z.B. das der Code einer Wicket-Komponente z.B. im Pfad src/main/java/de/wicketpraxis/ zu finden ist und das Markup in src/main/resources/de/wicketpraxis. ...

Wie in den Kommentaren der letzten Tage sichtbar wurde, eignet sich Wicket nicht "ungeschminkt" für Webseiten, die ihre Zustandsinformationen klassisch in URL-Parametern ablegen. In meinem Buch beschreibe ich eine einfache Variante, die bereits zum Ziel führen kann. ...

Ich habe mal ein wenig mit Scala rumgespielt und mit den Sprachmöglichkeiten, die Scala bietet, versucht aus einem Java-lastigen Wicket-Beispiel etwas zu machen, was sich wie Scala anfühlt. Zuerst der Java-Code: ...