Im Allgemeinen sprießen Webframeworks wie Pilze aus dem Boden. Mal mehr und mal weniger erfolgreich. Allerdings haben die meisten immer den gleichen MVC-Ansatz. Daten werden im Model vorgehalten, der Controller kümmert sich um die Bereitstellung der Objekte und der Navigation und das View “holt” sich alles was es braucht aus dem Kontext. D.h. man hat häufig eine Mischung aus HTML und einer expliziten Expression Language im View (z.B. JSTL).
Der große Nachteil bei dieser Form von Aufteilung ist, dass man beim Testen häufig auf verschiedene Frameworks zurückgreifen muss um die Korrektheit der Anzeige zu gewährleisten bzw. stark auf manuelles Testen angewiesen ist. Im Speziellen sei hier die Problematik von Text-Lokalisierung erwähnt, die jedem Entwickler im Laufe seiner Arbeit schonmal “auf die Füße gefallen” sein wird.
Einen etwas anderen Ansatz verfolgt an dieser Stelle das Framework Wicket. Hier wird bewusst auf eine explizite Expression Language verzichtet – soweit ich sehen kann. Alle Referenzen zwischen Controller und View werden über eine Wicket-Id-Tag (<span wicket:id="myMessage"></span>) aufgelöst. Damit steht zwar der Controller in der Pflicht alle Inhalte entsprechend umfangreicher aufzubereiten (z.B. explizite Änderungs-Propagierung), aber diese Vorgehensweise hat den elementaren Vorteil, dass Seiten wesentlich einfacher auch mit z.B. Junit-Tests geprüft werden können.
Es wäre alles zu schön um wahr zu sein, wenn es nicht schon auf den/meinen ersten Blick ein kleines Problem gäbe. Natürlich geht Wicket von einem MVC-Ansatz aus und benötigt damit HTML-Dateien zum Rendern. Leider wird standardmäßig davon ausgegangen, dass die HTML-Dateien im gleichen Verzeichnis liegen wie die entsprechende Klasse.
“First we need to create a web page. Wicket has a WebPage class suited for this task. All webpages need to be subclasses of WebPage. Another requirement is that the actual HTML file and the class name are equal: Index.html and Index, IndexPage.html and IndexPage or HelloWorld.html and HelloWorld. They also need to be in the same place on the classpath. The best way to develop is to put them in the same directory. This might seem strange in the beginning, especially when you are accustomed to separate html files and java files. However, since all pages are actually just components, it makes perfect sense in terms of reusability.”
(siehe hierzu http://cwiki.apache.org/WICKET/newuserguide.html#Newuserguide-TheHTML)
Für jeden Webentwickler, der es gewohnt ist, dass HTML- respektive JSP(X)-Dateien gefälligst weit weg von den Klassen zu liegen haben, eine Umstellung die nur leidlich zu ertragen ist.
Zum Glück haben die Wicket-Entwickler hier aber ein Einsehen und bieten in der Referenz-Dokumentation auch gleich mehrere Lösungen an, wobei aus meiner Sicht, die Maven-Lösung zu empfehlen ist, da sie versionsunabhängig ist.