Web Dynpro war gestern, UI5 ist heute? – Eine Einführung in SAP UI5 – Teil 3

Lesezeit ca. 5 Minuten

Dies ist der dritte Teil der mehrteiligen Blog-Reihe „Einführung zu SAP UI5“, in welcher wir Ihnen zeigen möchten, wie Sie Oberflächen mit der neuen SAP-Technologie UI5 entwickeln können. Im vorherigen Teil der Reihe haben wir uns mit der Einrichtung der Web-IDE beschäftigt und diese mit Ihrem SAP-System bzw. dem SAP-Demosystem „Northwind“ verknüpft. In diesem dritten Teil möchten wir Ihnen nun zeigen, wie die MVC-Architektur in UI5 funktioniert, aus welchen Komponenten eine Anwendung besteht und was eigentlich ein Framework ist.

Was Sie in diesem Artikel lernen

In diesem Artikel zeigen wir Ihnen:

1. Wie die MVC Architektur funktioniert
2. Aus welchen weiteren Komponenten eine UI5 Anwendung besteht
3. Was ein Framework ist

Komponenten einer Anwendung

MVC-Architektur

Im letzten Teil dieser Blog-Reihe haben Sie bereits die Struktur der Anwendung im Workspace gesehen:

Falls Sie schon Erfahrung mit der Oberflächenentwicklung haben, sehen Sie, dass es sich bei dieser Struktur um eine MVC Architektur handelt. Diese unterteilt Ihre Anwendung in

• Models, welche die Daten halten,
• Views, die für das Anzeigen der Oberfläche da sind und
• Controller, welche die Logik für Interaktion mit dem View enthält.

Durch die strikte Trennung dieser Aufgaben kommt es zu einem strukturierteren, übersichtlicheren Code, der sehr resistent gegen Fehler bei Anpassungen ist. Ändert sich etwas im Model, so müssen im Controller, wenn überhaupt, wenige Zeilen Code geändert werden.

Ein View enthält Controls (GUI Elemente) und ist ausschließlich für die Darstellung der Oberfläche sowie zum Weiterreichen von Events an den Controller zuständig. Wird im View ein Button gedrückt, wirft der View ein Event, welches im Controller abgefangen wird. Daten, die bspw. in ein InputField eingetragen werden, werden automatisch ins Model geschrieben, sofern das InputField mit einem Attribut des Models verknüpft ist (Data-Binding).

Ein Model definiert eine Struktur mit verschiedenen Attributen. Das Model kann über Data-Bindings mit einem View verknüpft werden. Die Datenweiterleitung kann dabei in nur eine oder in beide Richtungen gehen. Wird das Model verändert, aktualisiert es den View und wirft ein Event, welches im Controller abgefangen werden kann.

Der Controller enthält die Logik der Oberfläche. Er definiert (durch Methoden), was z.B. bei einem Button-Klick passieren soll und welche Daten wann nachzuladen sind. Zudem kann er den View um neue Elemente erweitern. Entwickelt wird ein View in SAP UI5 via JavaScript.

Erklärung weiterer Komponenten

i18n	i18n ist ein globales Model. Es enthält Texte, die in die Oberfläche eingebunden werden.
manifest	Enthält Metadaten zur Applikation und wird von der Component eingebunden.

Component

Eine Komponente ist das Wurzelelement einer SAP UI5 Anwendung. Sie beinhaltet Metadaten der Anwendung (ausgelagert in Manifest.json), sämtliche Views und Models. Dadurch, dass die komplette Programmlogik in einer Komponente gekapselt ist, können Anwendungen leicht in anderen Anwendungen eingebettet werden. Es müssen lediglich die Component und ein ComponentContainer erstellt werden. Eine Component erbt von der abstrakten Klasse sap.ui.core.Component oder sap.ui.core.UIComponent, je nachdem, ob die Component eine Oberfläche bereitstellt oder nicht. Durch Container und Component können Anwendungen sehr leicht gekapselt werden.

index.html

Bei einer Anwendung, die nicht aus dem Fiori Launchpad oder als Bestandteil einer anderen Anwendung gestartet wird, ist die index.html der Einstiegspunkt in Ihre Anwendung. Hier werden Pfade zu Ressourcen definiert und das SAP UI5 Framework gestartet. Ab hier wird die Programmflusskontrolle an das Framework abgegeben, d.h. alles läuft über SAP UI5. Sie fügen Ihren Code nur noch an den vorgesehenen Stellen ein. In der index.html müssen Sie keinen Code einfügen.

Arten von Views

In SAP UI5 gibt es 4 verschiedene Arten von Views. Es gibt XML-Views, JavaScript-Views, HTML-Views und JSON-Views.

Besonders zu empfehlen ist der XML-View. Denn zum einen ist XML-Code übersichtlicher als bspw. JSON, zum anderem steht Ihnen bei einem XML-View der Layout Editor zur Verfügung. Durch diesen Layout Editor ist es relativ einfach, Views per Drag and Drop zu erstellen und Event-Handler und Bindings zu definieren.

JavaScript-View wiederum ist dann zu empfehlen, wenn Sie Ihre Oberflächen sehr einfach komplett dynamisch generieren wollen.

Parallelen zu Web Dynpro

Da Web Dynpro ebenfalls auf einer MVC Architektur basiert, möchte ich Ihnen kurz einen Überblick über die entsprechenden Komponenten in einer Web Dynpro Anwendung geben.

Wie Sie im Bild oben sehen, ist die Architektur sehr Ähnlich. In Web Dynpro verbirgt sich hinter dem „View“ in der Leiste links der eigentliche View, das Model und der Controller. Der Unterschied zu UI5 ist, dass hier der View, Model und Controller übersichtlicher in einem „View“ zusammengefasst werden, die grundlegende Funktionsweise ist aber identisch. Der Componentcontroller entspricht in etwa der Component.js (und einem zusätzlichen Model), im Gegensatz zu Web Dynpro wird hier aber keine Geschäftslogik implementiert. Die Web Dynpro Anwendung entspricht der index.html.

Exkurs: Was ist ein Framework?

Frameworks sind Softwaregerüste. Sie erledigen allerhand Verwaltungsarbeit sowie andere generische Aufgaben, stellen aber keine Geschäftslogik bereit. Die Geschäftslogik wird vom Entwickler in speziellen Methoden implementiert, die vom Framework aufgerufen werden. Der Entwickler merkt und weiß im Optimalfall nur wenig vom Framework. Im Fall von UI5 kümmert sich das Framework u.a. darum, dass

• Views, Controller, Models instanziert werden,
• die MVC Architektur umgesetzt wird und
• GUI Elemente sowohl auf Smartphones, auf Tablets und Computern richtig dargestellt werden werden

In der obigen Abbildung wird deutlich, wie ein Framework arbeitet. Von dem, was das Framework alles leistet, bekommt der Entwickler jedoch nichts mit. Die Vereinfachung und Fokussierung für den Entwickler auf die Geschäftslogik ist das Hauptziel eines Frameworks:

1. Das Framework wird von der Anwendung aufgerufen. Ab jetzt ist das Framework das „Hauptprogramm“ (es hat den Kontrollfluss) und ruft nur noch an bestimmten Stellen den Code des Entwicklers auf.
2. Das Framwork kommt an eine Stelle, bei der eine Hook-Methode aufgerufen wird. Beispielsweise die Methode beforeRendering( ) eines View-Controllers (Hook-Methoden werden in UI5 wie Events behandelt).
3. Hat der Benutzer eine Eingabe getätigt, so registriert das Framework diese Eingabe und ruft – sofern implementiert – den entsprechenden Ereignisbehandler des Benutzers auf.

Kontrollfragen

Um Ihr erlangtes Wissen zu überprüfen, versuchen Sie die folgenden Fragen zu beantworten:

1. Beschreiben Sie die Aufgaben des Models, Views und des Controllers jeweils in einem Satz.
2. Angenommen, eine Methode im Controller ändert ein Attribut im Model, welches mit einem Control im View verknüpft ist. Ändert dann der Controller oder das Modell den View?
3. Wieso macht es Sinn, UI5 als Framework und nicht bspw. als Bibliothek bereitzustellen?

Die Antworten auf diese Kontrollfragen finden Sie wieder in der Einleitung des nächsten – vierten – Teils dieser Blog-Reihe, welcher nächste Woche erscheinen wird.

Ausblick

Mit dem nun erlangten – zugegeben recht theoretisch-technischen – Wissen sind Sie bereit, im nächsten Teil dieser Reihe Ihre erste eigene SAP UI5 Anwendung zu implementieren. Diese wird zwar noch sehr einfach sein, aber Sie werden bereits einen View, einen Controller und ein Model implementieren und miteinander interagieren lassen. Außerdem werden Sie sehen, wie einfach Sie das i18n Model verwenden können und wie Sie vom Framework weitere Resourcen anfordern.

Haben Sie Fragen, Anregungen, positive oder negative Kritik? Oder möchten Sie bestimmte Punkte des Artikels noch näher erläutert bekommen? Dann schreiben Sie gerne einen Kommentar oder kontaktieren Sie uns.

Vorherige Artikel dieser Reihe