Zur├╝ck zum Blog

Hochzeit

­čôů  

Ember-Rails

Unter Hochzeit versteht man in der Automobilindustrie die Vereinigung von Fahrgestell, Motor und Karosserie, die zun├Ąchst als Komponenten hergestellt wurden.

So eine ├Ąhnliche Hochzeit stand nun f├╝r unsere in Ember.js geschriebene Client-Applikation der Vertragskalkulation mit dem restlichen Webshopsystem ins Haus.

Zur Integration der beiden gibt es das Ember-Rails Gem: https://github.com/emberjs/ember-rails

Es stellt das Asset Handling komplett unter die Kontrolle der Rails Asset Pipeline. Die Umstellung diesbez├╝glich, sowohl f├╝r Entwicklungs- als auch f├╝r Produktivumgebung, war in etwas mehr als einem Tag zu schaffen. Hier haben wir wieder alle als Team am gleichen Problem gearbeitet, da wir diese Integration f├╝r eine wesentliche Komponente mit Zukunftsfolgen halten.

Zuvor haben wir noch s├Ąmtliches Javascript der Applikation einheitlich auf Coffeescript umgestellt. Dies hat zwar mehr Konsistenzgr├╝nde als realen Nutzen, war aber immerhin eine gute ├ťbung zur Festigung unseres CoffeeScript-Know Hows.

Die Kopplung der Datenmodelle zwischen Frontend und Backend ist implementiert, wir k├Ânnen nun alle Daten automatisch im Hintergrund ├╝bertragen, wenn dies vom Vertriebsmitarbeiter angefordert wird.

Promises

Wir m├╝ssen hier kurz auf das Konzept der Promises zu sprechen kommen, da es f├╝r uns alle neu ist. Bei asynchroner Programmierung erh├Ąlt man als R├╝ckgabewert auf einen Funktionsaufruf nicht des ermittelte Ergebnis, wenn dieses denn in Folge ermittelt worden ist, sondern nur ein Objekt, eben ein Promise, dieses aber unmittelbar ohne Zeitverz├Âgeruung. Es handelt sich dabei quasi um ein Versprechen auf einen R├╝chgabewert, die eigentliche Funktion wird asynchron, man k├Ânnte sagen im Hintergrund, ausgef├╝hrt. Ein Promise wird in Folge im Erfolgsfall erf├╝llt (fulfilled) oder im Fehlerfall zur├╝ckgewiesen (rejected), z.B. wenn der Server die Anfrage nicht akzeptiert. Auf Fehler- und Erfolsfall kann dann synchron geantwortet werden.

Dieses Konzept zu verstehen, ist ein Schritt, es erfolgreich zu verwenden und das Behandeln der Promises richtig zu implementieren ein weiterer. Selten ist uns bisher ein Programmierparadigma so fundamental vorgekommen, vergleichbar etwa mit Objektorientierung oder dem MVC Pattern. Es erm├Âglich eine v├Âllig neue Art der funktionalen Programmierung, im Internet teilweise ÔÇťreaktive ProgrammierungÔÇŁ genannt.

Immer wieder waren wir - bei falscher asynchroner Implementierung - ├╝berrascht keine R├╝ckgabewerte zu erhalten, dabei haben wir diese durch Ignorierung der Promises einfach ignoriert oder das Ergebnis nicht synchron abgewartet.

Single Page Apps

Ember.js Applikationen sind typischerweise Single Page Apps, so auch unsere Applikation. In derartigen Applikationen ist es ├╝blich, nur ge├Ąnderte Bildschirmbereiche zu aktualisieren, nicht aber von einer Sicht auf eine andere zu wechseln, was wir allerdings noch derzeit machen. Wir senden den Benutzer zwischen der Vertragsliste,


Vertragsliste


der Einzelansicht eines Vertrages mit seinen Positionen und der


Vertrag


Einzelansicht einer Vertragsposition mit ihren Verbr├Ąuchen hin und her.


Vertragsposition


Das ist eigentlich f├╝r Single Page Apps un├╝blich und wir beschlie├čen dieses Verhalten zu ├Ąndern.

Bei aller Begeisterung f├╝r unsere neue Applikation stellen wir im Test in der Wochenbesprechung fest, dass Positionen nicht gel├Âscht werden k├Ânnen und ├änderungen nicht am Server persistiert werden. Es gibt noch einiges zu tun!

Zur├╝ck zum Blog