Das Internationalisierungsprinzip von GWT ist an sich sehr einfach. Man nehme ein paar properties-Dateien, inkludiere das I18N-Modul und lasse sich die entsprechende Java-Datei generieren. Soweit so gut. Leider nicht so, wenn man den UIBinder verwenden möchte. Hier haben sich bereits diverse verzweifelte Entwickler einen “abgebrochen” um herauszufinden, welche Dateien an welcher Stelle liegen müssen, damit man in den jeweiligen ui.xml-Dateien eine vernünftige Übersetzung erhält.

Grundsätzlich gilt, dass Übersetzungs-Keys aus ui.xml-Dateien immer im Package com.google.gwt.i18n.client mit dem Namen LocalizableResource_[locale].properties liegen müssen. Diesen Umstand verdanken wir dem MessagesWriter, der vom UiBinderGenerator herangezogen wird. Dieser generiert zwar die Messages-Dateien für alle Keys, die sich in einer ui.xml-Datei befinden in eine eigene Messages-Klasse, importiert aber mittels

writer.write("import static com.google.gwt.i18n.client.LocalizableResource.*;");

ausschließlich die Übersetzungen aus LocalizableResource. Soweit so gut, möchte man meinen. Problematisch wird es dann, wenn man Übersetzungen sowohl im Java-Code, als auch im in den ui-Dateien haben will. Typisches Beispiel sind hier Tabellen vom Typ CellTable, deren Spalten normalerweise in den View-Klassen definiert werden. Will man hier nun sprachlich angepasste Spaltenköpfe haben, muss man diese mittels einer Messages-Klasse übersetzen.
In diesem Moment steht man vor der Frage: Möchte ich zwei Übersetzungsdateien verwalten, in denen ggf. Keys doppelt auftreten, oder möchte ich nur Eine für beide Mechanismen haben?

Ohne auf die unsäglichen und teilweise unpraktikablen Varianten einzugehen, die sich im Netz bereits befinden bzw. die kryptisch auf der GWT-Dokumentation vorgestellt wurde, stelle ich hier meine zwei Lösungen vor, die ich für sinnvoll erachte.

Variante 1: ui:with

Die klassische Variante. Man nehme einfach die existierenden Messages und importiere sie wie folgt in die ui.xml-Datei.

 <ui:with field='messages' type='com.my.app.MyMessages'/>
 <g:Label text="{messages.hello}" />

Diese Variante hat den Vorteil, dass man auf die komplette Bandbreite der Erweiterungen, die für Messages-Klassen bereitgestellt wurde zugreifen kann.

Variante 2: Customized Messages-Interface

In Variante 1 nutzen wir den Mechanismus, der eigentlich für den Java-Code gedacht war für den UiBinder. Natürlich geht es auch anders herum. Wir “kopieren” einfach den Mechanismus der MessagesWriter-Klasse. Wir bauen uns ein Interface und importieren die LocalizableResources.

package com.mypackage;

import static com.google.gwt.i18n.client.LocalizableResource.*;

public interface MyAppMessages extends Messages {
  @DefaultMessage("Example")
  String example();
}

Der GWT-Compiler greift hier einfach das Interface und verknüpft die Methoden mit den Keys aus der jeweiligen LocalizableResource-Datei. Damit lassen sich auch innerhalb von Java-Dateien die Keys aus LocalizableResource verwenden.

Achtung:
Leider gibt es nicht die Möglichkeit LocalizableResource-Dateien über den i18n-Aufruf in eine Klasse übersetzen zu lassen, da LocalizableResource bereits ein existierendes Interface ist und die Übersetzung zu einer sogenannten zyklischen Vererbung führt.

Fazit

Mit beiden Varianten lässt sich das bestehende Problem lösen, dass man nur einen Mechanismus zur Internationalisierung innerhalb von GWT-Projekten nutzen möchte. Welche der beiden zum Einsatz kommt hängt stark von der bestehenden Struktur und – was nicht zur vernachlässigen ist – von der Motivation des Entwicklers, welche Schritte für ihn in seinem Arbeitsprozess besser integriert werden können, ab. Während Variante 1 den Aufruf des i18n-Creators erfordert, muss in Variante 2 das Interface immer manuell angepasst werden.

Nachdem ich bereits über einen Workaround für GWT 2.1 bezüglich des RequestFactory-Einsatzes mit Spring gesprochen habe war für mich vor allem das neue RequestFactory-API interessant. Dieses hat jetzt in u.a. in der Service-Annotation einen locator mit dem man auf Klassen referenzieren kann, die keine statischen Methoden enthalten. Ein schönes Beispiel für den Einsatz findet sich in der GWT Google Group (zugehöriger Thread).

Der folgende Auszug ist aus dem eben genannten Thread.

public class SpringServiceLocator implements ServiceLocator {
        @Override
        public Object getInstance(Class<?> clazz) {
                HttpServletRequest request = RequestFactoryServlet.getThreadLocalRequest();
                ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(request.getSession().ge tServletContext());
                return context.getBean(clazz);
        }
}

“I annotate my RequestContext with the GWT @Service annotation (not the
Spring one). Example below:”

@Service(locator = SpringServiceLocator.class, value =
AddressService.class)
public interface AddressRequest extends RequestContext {
        // Get address by id
        Request<AddressProxy> get(Long id);
}

Die Entwickler der RequestFactory haben sich nämlich ein schönes Konstrukt in der Klasse ReflectionBasedOperationRegistry ausgedacht, welches es nur gestattet entweder statische Methode oder eine Methode der Entity selbst aufzurufen.

boolean isInstance = InstanceRequest.class.isAssignableFrom(requestMethod.getReturnType());
if (isInstance == Modifier.isStatic(domainMethod.getModifiers())) {
  throw new IllegalArgumentException("domain method " + domainMethod
          + " and interface method " + requestMethod
          + " don't match wrt instance/static");
}

Zur allgemeinen Verteidigung: in der kommenden Version GWT 2.1.1 wurde diese Einschränkung angeblich schon ausgebaut. Da zum aktuellen Zeitpunkt allerdings nicht klar ist, wann diese Version veröffentlicht wird, muss man sich mit anderen Mitteln behelfen. Eines dieser Mittel möchte ich kurz vorstellen.

Die Idee hinter dem ganzen ist es einen Adapter zu schreiben, der die notwendigen statischen Methoden für die RequestFactory bereitstellt und diese an den eigentlichen Service delegiert.
Ich gehe davon aus, dass der Leser mit dem Grundprinzip der GWT RequestFactory vertraut ist. Falls nicht, empfehle ich einen Blick auf diese Seite.

Als Erstes möchte ich die RequestFactory vorstellen:

public interface SampleRequestFactory extends RequestFactory {

    @Service(SampleRequestAdapter.class)
    interface SampleRequestContext extends RequestContext {
        Request<List<SampleEntityProxy>> findAll();
    }

    SampleRequestContext sampleRequestContext();
}

Für diejenigen, die sich mit Spring auskennen sei darauf hingewiesen, dass die obige Service-Annotation nicht die von Spring, sondern die von GWT ist.

Weiter im Text …

Der entsprechende Adapter könnte in etwa so aussehen.

public class SampleRequestAdapter {

    private static SampleService _sampleService;

    public static void setApplicationContext(ApplicationContext applicationContext) {
        _sampleService = applicationContext.getBean(SampleService.class);
    }

    public static List<SampleEntity> findAll() {
        return _sampleService.findAll();
    }
}

Soweit, sogut. Bisher ist noch nichts Spannendes passiert. Dennoch ist die Luft bereits erfüllt mit “Entwickler-Magie”. Die offene Frage ist nämlich: Wie wird die Methode setApplicationContext() aufgerufen?

Die Lösung ist zwar nicht zwingend schön, aber wirkungsvoll:

• Man nehme eine Klasse, die von Spring verwaltet wird.
• Mache diese Klasse ApplicationContextAware.
• Gebe dieser Klasse die Adapter als Parameter und rufe für alle die Setter-Methode auf.

Im Code-Gewand sähe dies so aus:

public class ApplicationContextProvider implements ApplicationContextAware {
    private List<Class> _requestAdapters;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        if (_requestAdapters != null) {
            for (Class requestAdapter : _requestAdapters) {
                try {
                    final Method setter = requestAdapter.getDeclaredMethod("setApplicationContext", ApplicationContext.class);
                    if (Modifier.isStatic(setter.getModifiers())) {
                        setter.invoke(requestAdapter, applicationContext);
                    }
                // ... exception handling code
            }
        }
    }

    public List<Class> getRequestAdapters() {
        return _requestAdapters;
    }

    public void setRequestAdapters(List<Class> requestAdapters) {
        _requestAdapters = requestAdapters;
    }
}

Abschließend muss der Provider selbstverständlich noch für Spring verfügbar gemacht werden.

<bean class="de.sampleproject.ApplicationContextProvider">
  <property name="requestAdapters">
    <list>
      <value>de.sampleproject.SampleRequestAdapter</value>
    </list>
  </property>
</bean>

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.