Expression Bindings – Eine Alternative zum formatter

“Ausdrucks Bindungen”? Was’n das? Klingt jetzt erst mal kompliziert. Weil ist ja auch Englisch. Aber so kompliziert ist es gar nicht. Expression Bindings beschreiben die Möglichkeit, Werte eines Models direkt im View anzupassen. Die Logik steht dabei mit im View, wodurch man sich die Auslagerung in externe Dateien (z.B. in die eines formatters) spart.

Das Prinzip des Bindings sollte bekannt sein, bei dem Werte aus einem Model auf einen View bzw. auf die dort sich befindlichen Controls und deren Eigenschaften gelegt werden.

<Label
  text="{id}" />

Aber was macht man eigentlich, wenn man die Daten aus einem Model nicht 1 zu 1 im View anzeigen möchte? Hier gibt es mehrere Möglichkeiten:

Die erste Lösungsmöglichkeit, die ich kennen gelernt habe, ist der sogenannte formatter.
Der formatter ist eine ausgelagerte Java-Script Datei, die beliebig viele Funktionen zur Modifikation der Anzeige einzelner Werte beinhalten kann. Die Aufrufe der Funktionen werden im View mit hinterlegt.

<Label
  text="{ path: ‚id‘, formatter:‘.formatter.makeIdGreatAgain‘}" />

In diesem Beispiel wird die die Funktion „makeIdGreateAgain“ mit dem Parameter „id“ aus dem formatter aufgerufen. Der return-Wert dieser Funktion wird anschließend im View angezeigt.
Eine entsprechende Funktion im formatter könnte wie folgt aussehen:

function: makeIdGreatAgain(pId) {
  return   pId.toUpperCase();
}

Und man kennt ja wie das ist: Wenn man die Lösung eines Problems kennt, dann benutzt man diese auch, ganz gleich, ob es alternative bzw. auch in gewissen Fällen bessere Lösungsmöglichkeiten gibt. Frei nach dem Motto: “Bloots nich noh Rechts un Links kieken!”

Ich möchte in diesem Artikel eine weitere Möglichkeit vorstellen, diese Anforderung umzusetzen und auch eine, zugegebenermaßen subjektive Empfehlung geben, wann diese sinniger ist als die Option des formatters.

“Here we go, welcome Expression Bindings!”

Einfaches-/Komplexes Beispiel

Wie schon beschrieben stellen die Expression Bindings eine Möglichkeit dar, direkte Anzeigelogik in einen View zu integrieren. Ein einfaches Beispiel ist die Umkehrung eines Boolean Wertes.

<Label
  text="{id}"
  visible="{= !${hidden} }" />

Die Syntax sieht wie folgt aus: Eine Expression Binding wird immer umschlossen von geschweiften Klammern samt eines Gleicheitszeichens („{= … }“). Wenn innerhalb der geschweiften Klammern auf Felder eines Models zugegriffen werden sollen muss vor den (inneren) geschweiften Klammern ein Dollarzeichen stehen „${…}“.

Es lassen sich beliebige Kombination von Expression Bindings realisieren. Beispielsweise können auch mehrere Felder eines Models in einer Expression Binding berücksichtigt werden. Ein etwas komplexeres Beispiel stellt folgender Aufruf dar:

<Label
  text="{= ${id} === ${oldId} ? ‚IDs stimmen überein‘ : ‚IDs sind unterschiedlich‘ }"
  visible="{= !${hidden} }" />

Die Berechnung der Expression Bindings wird immer neu durchgeführt sobald sich ein Feld im Model ändert. („One-Way-Binding“)

Alternativ dazu gibt es noch die Möglichkeit bei den umschließenden, geschweiften Klammern vor das Gleichheitszeichen einen Doppelpunkt zu schreiben („{:= … }“). Im Gegensatz zur beschriebenen Variante wird die Logik hier nur einmal aufgerufen und berücksichtigt keine Änderungen an den Werten. („One-Time-Binding“)

Operatoren

Es gibt eine Vielzahl an Operatoren, die in Expression Bindings verwendet werden können. Ich habe mal die gängigsten in einer Tabelle zusammengefasst.

Beschreibung Operator
Nicht (not) !
Und && (&amp;&amp;)
Oder ||
If … then (Boolean) ? (trueThingie) : (falseThingie)
Gleich ===
Ungleich !==
Größer, Kleiner >, <, >=, <=

Eine Besonderheit stellt hier der UND-Operator dar, welcher in einem Aufruf maskiert werden muss. Geschieht das nicht kann der View nicht gerendert werden. (Eine mögliche Fehlerquelle bei Expression Bindings)

<Label
  text="{id}"
  visible="{= !${hidden} &amp;&amp; ${id} === ${oldId} }" />

Wann machen Expression Bindings Sinn?

Das ist eine Frage, die ich nicht pauschal beantworten kann. Es hängt viel mit den Vorlieben eines Entwicklers zusammen, ob, wann und wie Expression Bindings eingesetzt werden. Wenn man radikal zu Werke geht kann man sämtliche Anforderungen mit Expression Bindings darstellen und auf einen formatter komplett verzichten. Andersrum geht es natürlich genauso.

Meine subjektive Meinung dazu ist:

Expression Bindings machen dann Sinn, wenn sie kurz sind und keine Texte als Ausgabe beinhalten. Klipp und klar, nichts weiter. Zusätzlich verlieren sie für mich ihre Vorteile, wenn sie zu komplex werden und/oder es nicht auf den ersten Blick erkennbar ist, was da jetzt genau passiert.

Für mich heißt das in der Praxis, dass ich Expression Bindings in 90% der Fälle bei den Control-Eigenschaften „visible“ und „enabled“ verwende. Oder anders ausgedrückt: Immer, wenn ein Boolean berechnet wird. Andere Berechnungen lagere ich dagegen (oft) in einen formatter aus.
Wenn die Logik allerdings zu komplex wird ziehe ich die Berechnung von Boolean-Werten auch in einem formatter vor.

Des Weiteren halte ich nichts davon, wie in dem komplexeren Beispiel oben zu sehen, mit Expression Bindings Textausgaben zu machen.
Das hat den einfachen Grund, dass in Expression Bindings die Internationalisierung nicht berücksichtigt werden kann. Heißt unter anderem auch, dass folgender und ähnliche Aufrufe nicht (wie gewünscht) funktionieren werden:

  <Label
  text="{= ${id} === ${oldId} ? ${i18n>label01} : ${i18n>label02} }"
  visible="{= !${hidden} }" />

Fazit

Das Prinzip der Expression Bindings sollte einem SAPUI5 Entwickler auf jeden Fall geläufig sein, da sie unter gewissen Voraussetzungen eine gute und elegante Methode darstellen gewünschte Anforderungen umzusetzen.
Auch kann es natürlich mal vorkommen, dass man jemand anderes Code vor der Nase hat, der diese verwendet. (Die SAP tut dies in seinen SAPUI5-Templates übrigens auch) Der kurze Überblick sollte schon ausreichen, dass die Funktionen auf den ersten Blick verstanden und auch angepasst werden können.

Ob und wie man sie einsetzt ist natürlich weiterhin jedem selbst überlassen.

Bis dahin erstmal und: “Kiek mol wedder in!”Du interessierst dich für Fiori und hast Lust coole Projekte mit uns zu machen? Wir suchen dich! Schau doch mal in unserer Stellenbeschreibung vorbei.

 

 

Über den Autor

Sebastian Kielhorn

Kommentar verfassen