SAPUI5: Typen von Views

Wie im Beitrag SAPUI5: Ein paar Grundlagen zum SAPUI5-Framework schon erwähnt unterstützt das SAPUI5-Framework unterschiedliche Typen von Views:

  • JavaScript-View
  • XML-View
  • JSON-View
  • HTML-View

In diesem Artikel werden nun, auf Basis eines gemeinsamen UIs, die Unterschiede der einzelnen View-Typen aufgezeigt. Dafür wird ein einfacher Dialog jeweils als JavaScript-, XML-, JSON– und HTML-View umgesetzt.

User-Interface und Projektstruktur

Das SAPUI5-Framework unterstützt die folgenden Typen von Views:

View-TypenDateiendung
JavaScript-View*.view.js
XML-View*.view.xml
HTML-View*.view.html
JSON-View*.view.json

Um nun die Implementierung und Unterschiede der einzelnen View-Typen besser betrachten zu können hier mal ein einfaches Beispiel. In diesem Beispiel wird ein ganz simples UI jeweils als HTML-, JavaScript-, JSON– und XML-View implementiert. Das UI orientiert sich dabei an den gängigen Hello World Beispielen:

Der angezeigte Button befindet sich innerhalb eines sap.m.Panel (https://sapui5.hana.ondemand.com/#docs/api/symbols/sap.m.Panel.html) und das Panel wiederum ist innerhalb einer sap.m.Page (https://sapui5.hana.ondemand.com/#docs/api/symbols/sap.m.Page.html) angeordnet. Beim Klick auf den Button soll einfach eine Messagebox mit dem Text „Hello World!“ ausgegeben werden. Die Projektstruktur innerhalb von Eclipse sieht dabei wie folgt aus:

Projektstruktur

Projektstruktur

Die Instanziierung der Views erfolgt jeweils über eine eigene *.html-Seite (z.B. index_xml_view.html), dabei wird lediglich der Typ des Views angepasst (Zeile 21):

Der View-Typ selbst ist als Enumeration definiert. Siehe dazu hier: https://sapui5.hana.ondemand.com/#docs/api/symbols/sap.ui.core.mvc.ViewType.html

Um die Funktionalität der Anzeige einer Messagebox nicht in jedem View neu zu implementieren gibt es einen gemeinsam genutzten Controller, der in allen Views Verwendung findet. Der Controller ist wie folgt aufgebaut:

Nachfolgend nun die unterschiedlichen View-Typen und die jeweilige Implementierung.

JavaScript-View

JavaScript-Views bieten die größte Flexibilität, da sie reinen JavaScript-Code enthalten. Dadurch ist es möglich UI-Elemente dynamisch zu erzeugen, z.B. auf Basis von Modelldaten). Hier mal ein Beispiel für einen JavaScript-View:

Wie zu sehen werden die einzelnen View-Objekte mit den new-Operator erzeugt und dann dem jeweiligen Root-Element zugewiesen. Dabei kann die Erzeugung der Elemente in einer beliebigen Reihenfolge stattfinden und das UI kann ganz nach Bedarf zusammengestellt werden.

Vorteile:

  • Objektorientierte Erzeugung der Views (es ist möglich beliebige Objekte zu instanziieren und Methoden auf diesen Objekten aufzurufen, darüber hinaus können alle JavaScript-Funktionen verwendet werden (z.B. loops))
  • Seiten können dynamisch aufgebaut werden
  • man entwickelt die ganze Zeit in JavaScript und muss nicht hin und her wechseln (JavaScript – XML)

Nachteile:

  • Hier ist die Versuchung groß View und Anwendungslogik miteinander zu vermischen
  • schwerer lesbar bei großen, verschachtelten Views

XML-View

Der SAPUI5 Developer Guide empfiehlt, wann immer es möglich ist, die Verwendung von XML-Views. Der große Vorteil der XML-Views ist, dass sie automatisch validiert werden können. Aufgrund der hierarchischen Struktur, kann man sich bei XML-Views leicht ein Bild vom späteren Layout machen. Das oben gezeigte Layout sieht als XML-View so aus:

Im Gegensatz zum oben gezeigten JavaScript-View ist der XML-View schon um einiges kompakter. Innerhalb von JavaScript-Views können die UI-Elemente an beliebiger Stelle erzeugt werden. In XML-Views müssen diese an der korrekten Stelle stehen, dies macht es aber auch einfacher sich ein Bild vom späteren Layout zu verschaffen.

Exkurs WPF

Würde man das oben gezeigte UI in WPF umsetzen könnte das wie folgt aussehen:

Auf den ersten Blick sind die Unterschiede gar nicht so gravierend. Der grundsätzliche Aufbau ist gleich, die Unterschiede liegen hauptsächlich in den verwendeten Controls bzw. UI-Elementen. Auch das DataBinding innerhalb von SAPUI5 ist dem von WPF recht ähnlich, darauf werde ich in einem weiteren Beitrag genauer eingehen.

Vorteile:

  • bei der Verwendung von XML-Views ist man gezwungen View und Logik strikt zu trennen (Separation of Concerns), dies ist vor allem beim Einsatz des MVC-Patterns hilfreich
  • bessere Lesbarkeit
  • weniger Quellcode -> bessere Wartbarkeit

Nachteile:

  • keine dynamische Erzeugung von UI-Elementen bzw. Controls

JSON-View

Bei XML und JSON wird man sich vielleicht die Frage stellen, warum XML bevorzugt wird. JSON ist moderner und hat eine kleinere Dateigröße bzw. kann kompakter geschrieben werden. Das oben gezeigte UI wird als JSON-View wie folgt implementiert:

Angenommen wir haben ein großes, geschachteltes UI und möchten ein neues UI-Element einfügen. Innerhalb eines XML-Views hat man die Stelle für das Einfügen recht schnell gefunden. Bei einem JSON-View hingegen ist das, auf den ersten Blick, nicht so schnell ersichtlich. Hat man die richtige Stelle dann ausgemacht geht es an die richtige Zeichensetzung von „}“- bzw. „]“-Zeichen und dies kann schwieriges Unterfangen sein! Das JSON-Format ist recht empfindlich was die Zeichensetzung angelangt! Eine schließende } kann man schnell vergessen bzw. übersehen; ein schließendes </Button>, innerhalb eines XML-Views, ist wesentlich schneller zu finden bzw. besser zu lesen.

Bisher konnte ich keine wirklichen Vorteile bei JSON-Views feststellen. Im Internet finden sich auch nicht wirklich viele Beispiele für diesen Typ von View und im Developer Guide ist darüber auch nicht wirklich viel zu finden.

HTML-View

Zum Schluss noch das oben gezeigte UI als HTML-View:

Hier ist es ähnlich den JSON-Views. Wirkliche Vorteile konnte ich keine finden und der Developer Guide gibt auch nicht viel her.

Feature Matrix

Wie bereits geschrieben sind JavaScript– und XML-Views die gängigsten Optionen was die UI-Entwicklung unter SAPUI5 angeht. Diese View-Typen bieten auch gleichzeitig die meisten Funktionen. Hier mal eine Feature-Matrix für die einzelnen View-Typen:

FeatureJavaScript-
View
XML-
View
JSON-
View
HTML-
View
Eigenschaften vom Typ string,
integer, boolean, float
jajajaja
Eigenschaften anderer Typen
(Objekt)
janeinneinnein
einzelne Ereignis-Listener-
Registrierung
jajajaja
mehrere Ereignis-Listenerjaneinneinnein
einfaches Data Binding
(z. B. Pfad, benanntes Model, ...)
jajajaja
benutzerdefiniertes Data
Binding (z. B. Formatter,
Datentyp, Factory-Ansatz)
jajaneinnein
eingebettetes HTML (ohne
Einsatz der HTML-Controls)
neinjaneinnein
dynamische Erstellung von
Controls (z. B. auf Basis von
Modelldaten, jedoch außerhalb
der Data-Binding-Funktionen)
janeinneinnein
Codevervollständigungjajaneinnein
Vorlagenjajaneinnein
Validierungneinjaneinnein
Typen von Views im Vergleich

Fazit

Der SAPUI5 Developer Guide empfiehlt, wann immer es möglich ist, die Verwendung von XML-Views. Wirft man einen Blick in die SAPUI5-Explored-App (https://sapui5.hana.ondemand.com/explored.html) wird man feststellen, dass alle Views als XML-Views implementiert wurden. Die SAP selbst entwickelt wohl auch alle neuen FIORI-Apps ausschließlich als XML-Views. XML ist derzeit die bevorzugte Methode zur Erstellung von Views, und die von SAP bereitgestellten Werkzeuge (wie der in der SAP Web IDE bereitgestellte Layout Editor) funktionieren aktuell nur mit XML-Views. Bei der Implementierung von Unit-Tests mit integriertem View-Code, sollten man JavaScript-Views nutzen. Im Grunde hängt das auch viel von persönlichen Vorlieben und dem jeweiligen Background ab: Jemand der aus dem .NET- bzw. WPF-Umfeld kommt wird sich, mit ziemlicher hoher Wahrscheinlichkeit, für XML-Views entscheiden. Entwickler die aus dem Java-Umfeld kommen werden wohl eher zu JavaScript-Views tendieren. Zu HTML– und JSON-Views findet man dagegen kaum Beispiele und die Dokumentation dazu ist auch nicht wirklich umfangreich, daher sollte man eher auf XML– und JavaScript-Views setzen.

Literaturverzeichnis und Weblinks

Abk.Quelle
[1]SAPUI5 Developer Guide - Views
https://sapui5.hana.ondemand.com/#docs/guide/91f27e3e6f4d1014b6dd926
db0e91070.html

leave your comment

Fork me on GitHub