Rich Internet Applications mit ExtJS und Jersey
Kommentare

http 204 antwortet nicht
In der Antwort des Servers erwartet ExtJS JSON als Rückgabeformat und setzt voraus, dass immer das Feld success enthalten ist. Jersey hingegen verwendet den HTTP-Statuscode (z.

http 204 antwortet nicht

In der Antwort des Servers erwartet ExtJS JSON als Rückgabeformat und setzt voraus, dass immer das Feld success enthalten ist. Jersey hingegen verwendet den HTTP-Statuscode (z. B. 204 oder 404), um Erfolg oder Misserfolg anzuzeigen und gibt manchmal einen Leerstring oder sogar null als Content zurück. Um das zu beheben, wird die Methode readResponse des JsonReader überschrieben. Mit den Änderungen in Listing 6 erwartet ExtJS nur noch dann JSON Content, wenn der HTTP-Statuscode nicht 204 ist. Zudem führt das Fehlen von success nicht mehr zu einem Fehler.

Listing 6
Ext.override( Ext.data.JsonReader, { readResponse: function(action, response) {
  [...]  
  if (response.status !== 204) { // Avoid 'No Content'
      o[this.meta.root] = (response.responseText !== undefined) ? 
      Ext.decode(response.responseText) : response;
      if (!o[this.meta.root]) throw new Ext.data.JsonReader.Error('response');
  }
  //if (Ext.isEmpty(o[this.meta.successProperty])) 
  // here is the problem!
  //  throw new Ext.data.JsonReader.Error(.); 
  this.ef = this.buildExtractors();
  return o;
}});

Da für Jersey null ein gültiger Wert und kein Fehler ist, gibt der Server im Content null zurück, wenn die Ergebnismenge leer ist. Dann wird von ExtJS ein loadException Event generiert. Um das zu vermeiden, muss ein entsprechender Event Handler implementiert werden, der den Rückgabewert explizit abfängt.

Das unentdeckte Land

Die Architektur mit ExtJS und Jersey hat sich für unsere RIA bewährt. In dieser Kombination sind die Komponenten zwar neu und noch nicht vollständig erprobt, aber die Offenheit und Anpassbarkeit überwiegt die Risiken. Der Kunde erhält eine zeitgemäße Anwendung, die leicht änderbar und gut wartbar ist. Die gute Dokumentation des Frameworks, die große Community und das insgesamt durchdachte Programmiermodell von ExtJS erleichtern die Einarbeitung. Die erzwungene Entkopplung von Client und Server unterstützt kurze Entwicklungszyklen und somit eine schnelle Reaktion auf geänderte Anforderungen. Für agile Projekte ist diese Architektur also besonders zu empfehlen.

Die Beherrschbarkeit dieser Technologie für große Teams ist ein noch offener Punkt. Denn die Mächtigkeit von ExtJS und die Dynamik von JavaScript verführen geradewegs dazu, Geschäftslogik auch auf den Client auszulagern. Hier sollte man aber die Wartbarkeit der Anwendung im Blick behalten. Daher: wenn schon Logik auf dem Client, dann mit Bedacht und in erster Linie für GUI-zentrische Themen, z. B. Page Flow oder Validierungen. Die notwendigen Basiskonzepte wie Fehlerbehandlung müssen sauber ausgearbeitet und die Schnittstellen angemessen dokumentiert werden. Zusätzlich müssen sämtliche Prüfungen, speziell alle, die mit Security zu tun haben, noch einmal auf dem Server implementiert werden. Denn der Client der Webanwendung könnte leicht geändert und die dort implementierten Prüfungen entfernt werden.

ExtJS wird ständig weiterentwickelt. Aktuelle Themen sind eine erweiterbare Plug-in-Architektur und Unterstützung für Web Storage und Datenspeicherung auf dem Client. Auch mobile Endgeräte sind im Fokus. Es lohnt sich also dabei zu bleiben. Die gewählte Architektur mit ExtJS und REST ist tragfähig und wird zukünftig noch an Bedeutung gewinnen.

Juri Urbainczyk ist Bereichsleiter und IT-Berater bei der A:gon Solutions GmbH in Frankfurt. Seit mehr als 15 Jahren befasst er sich mit Webanwendungen und Softwarearchitekturen. Herr Urbainczyk konzipiert und entwickelt Portale und BI-Anwendungen für Kunden im Bereich Aviation und Touristik. Weitere Schwerpunkte sind Architekturaudits sowie Anforderungs- und Qualitätsmanagement.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -