Seite 3: Persistieren und Fazit

Inhaltsverzeichnis

Daten speichern

Auch für das Persistieren von Daten bietet Avatar mit seiner engen Bindung an EclipseLink eine einfache Lösung: die sogenannten Data Provider. Aktuell kommt Avatar mit zwei unterschiedlichen Varianten, einem sogenannten file data provider und einem database datasource provider. Für das Beispiel besteht die Aufgabe darin, beim Update der Server-Time Log-Einträge bestehend aus den beiden Namen und der Serverzeit zu speichern. Die View ist hierfür optisch nicht weiter anzupassen.

Zuerst ist ein entsprechender Daten-Provider bereitzustellen. Das erfolgt im bereits angelegten Service:

var logProvider = new avatar.FileDataProvider( 
    { filename: "log-entries.txt", key: "key" }); 

Ein weiterer Rest-Service übernimmt den Eintrag der einzelnen Logs. Statt einer $onGet-Methode wie im vorigen Beispiel ist nun ein anderer Callback notwendig. Mit $onPut wird der entgegengenommene Eintrag in den neuen logProvider geschrieben:

avatar.registerRestService({url:"data/logs/{entry}"},
   function() { 
      this.$onPut = function(request, response) {
         logProvider.$put(this.entry, request.data,function(result) { 
            response.$send(result); 
         }); 
      };
   } 
); 

Nach dem Service sind nun noch ein paar Zeilen Anpassungen in der View notwendig. Der erste Schritt ist das neue LogModel:

<script data-model="rest" id="LogModel"> 
   var LogModel = function() {
      this.key = '';
      this.value = '';
      this.init = function () { 
         this.key = name.first; 
         this.value = message; 
      }; 
   }; 
</script>

Neben dem Konstruktor ist eine init-Funktion vorgesehen, die das Modell neu befüllt. Der eingebundene Aufruf des REST-Service enthält eine Besonderheit. Mit dem Attribut data-onActive lässt sich die automatische Synchronisation mit dem Dienst verhindern. Das ist im vorliegenden Fall auch nicht gewünscht, da nur bei Bedarf ein entsprechendes Log zu schreiben ist.

<scriptdata-type="LogModel" data-instance="logEntry" 
data-url="data/logs/#{this.key}" data-onActive="noRefresh"></script> 

Letztlich bleibt nur noch dem Update-Button die neue Funktion im onClick-Attribut mitzugeben. Angepasst sieht der jetzt folgendermaßen aus:

<buttononclick="#{message.$get()};#{logEntry.init()};
#{logEntry.$put()}">Update</button>
 

Nach dem erneuten Laden der Seite sind die Änderungen gewohnt schnell aktiv und zum Ausprobieren bereit. Den Klick auf den Update-Button betrachtet man dabei am Besten mit dem Netzwerk-Tab der Chrome Developer Tools. Dabei ist der zusätzliche Put Request gut zu erkennen:

In der am File Data Provider konfigurierten Datei finden sich dementsprechend auch die Log-Einträge. Damit ist das kleine Beispiel soweit beendet. Die Avatar-Dokumentation und vor allem die mitgelieferten Musterprojekte sollten bei weiterführendem Interesse ausreichend Anleitung für erste eigene Gehversuche geben.

Fazit

Oracle hat die Zeichen der Zeit verstanden und eine spannende Kombination aus den Bemühungen der vergangenen Monate – in Form des Nashorn-Projekt oder dem JPA-RS in EclipseLink – geschnürt. Was bisher nach Einzelaktivitäten ausgesehen hat, ist auf einmal ein Produkt geworden – noch dazu unter einer Open-Source-Lizenz. Das das Projekt wieder auf java.net liegt und bisher keine Beschreibungen für eine Beteiligung der Open-Source-Gemeinde vorliegen, ist bei Oracle nicht verwunderlich. Zumindest können Entwickler Feedback über den Issue Tracker geben und mit acht Personen ist das Projekt-Team vergleichsweise groß.

Über die Zukunft von Avatar entscheiden mehrere Dinge: Zum einen kann es nur erfolgreich verbreitet werden, wenn es auch auf anderen Applikationsservern und Web-Containern wie WildFly oder TomEE lauffähig ist. Zum anderen müssten sich die Möglichkeiten zur Mitarbeit für die Nutzergemeinschaft deutlich verbessern.

In den bisherigen Projektvorstellungen hat Oracle immer wieder angedeutet, dass Avatar ein Bestandteil von Java EE 8 werden könnte. Nachdem es sich weniger um eine einzelne Technik als vielmehr um eine Kombination von bestehenden Spezifikationen mit deutlichem Framework-Charakter handelt, bleibt zu hoffen, dass Oracle von dem Gedanken wieder Abstand nimmt. Der Ansatz würde am Ziel vorbei führen.

Markus Eisele
ist Principal IT Architect bei der msg systems AG in München, Java EE 7 EG, JCP und iJUG e.V. Mitglied sowie Oracle ACE Director. (jul)