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.

Der Wrapper basiert auf dem Widget-Prinzip. D.h. alles ist ein Widget. Von der Seite bis zum Formular. Aktuell stehen folgende Widgets zur Verfügung:

• Page: Eine normale Seite
• Section: Seitenbereich, kann auch eine komplette Unterseite darstellen
• Form: normales Formular
• Menu: diverse Ausprägungen eines Menüs

Jedes Widget kann mit einem Template individualisiert werden. Diese können unter custom/templates erstellt werden, da sich unter widgets die Standardtemplates befinden und diese auch nicht geändert werden sollten. Beispiele befinden sich in dem Verzeichnis samples.

Download: pinc-soow.zip

Vor allem die Behandlung der OpenSocial-Mitgliedsplattformen gegenüber Entwicklern empfinde ich bis jetzt als extrem unhöflich. Bei MySpace muss man sich als Entwickler bewerben bekommt aber ggf. nie eine Antwort zurück, sondern darf sich irgendwann wieder neu bewerben. Bei den meisten Plattformen bietet die Sandbox nichtmal Unterstützung für den opensocial-Namensraum an, was allein die Entwicklung von sogenannten Gadgets mit dem entsprechenden Namensraum erlaubt.
Hinzu kommt, dass bestimmte Kernelemente nur optional sind und z.B. die ID des eingeloggten Benutzers über manuelle Requests nachgefragt werden muss. Dies erschwert die Kommunikation mit einer externen Applikation, welche für komplexere Anwendungen notwendig scheint und eigentlich durch eine simple URL-Referenz im Content-Tag möglich sein sollte.
Der dritte Punkt, der mich an OpenSocial stört ist die mangelhafte Dokumentation. Zwar wird im Einleitungsvideo auf der OpenSocial-Seite auf die großartige Dokumentation hingewiesen. Bei spezifischen Problemen lässt diese aber sehr zu wünschen übrig. So springt man permanent zwischen vielen gleichaussehenden Seiten hin und her um dann nach einigen Stunden endlich den notwendigen Link in einen Bereich zu finden, der aus dem Menü nichtmal zu erahnen ist. So findet man z.B. kaum oder gar nicht eine Übersicht über die möglichen Features, wie dynamic-heights, die man einbinden kann bzw. muss.

Für eine API, die – aus meiner Sicht – nur dafür geeignet ist kleine Funapplikationen zu entwickeln haben sich die OpenSocial-Betreiber bis jetzt nicht mit Ruhm bekleckert. Als Alternative zu Facebooks API ist es bis jetzt (immer) noch nicht zu sehen.