Quelltext der Seite Dynamic UI Fragment Composition

== Dynamic UI Fragment Composition ==
=== Herausforderungen ===
Die angestrebte Microservice-Architektur dient vorrangig der Verteilung von Verantwortung innerhalb des Projekts.  Im Sinne der Prinzipien Loosely coupling und High Cohesion ist also auch die Einführung eines zentralen User Interface (UI) Services nicht zielführend. Dies impliziert, dass die diversen kleinen Projektteams für ihre Microservices einschließlich der UI verantwortlich sind.

Neben der angesprochenen Verteilung der Verantwortung sind aber auch grundlegende Prinzipien der Human-Computer-Interaction (HCI) und ein Corporate Design (CD) zu realisieren. Wie ein derartiges, einheitliches Look & Feel erreicht werden kann, beschreibt das vorliegende Konzept. Neben der Umsetzung nicht-funktionaler Anforderungen, welche im Folgenden dokumentiert werden, gilt es ebenso informelle Beschreibungen des Verhaltens der Microservices zu beachten. Letzteres muss wiederum durch neue Mechanismen im sozialen System sichergestellt und implementiert werden.

=== Lösung ===
Der Pool² wird als Rich-Internet-Application (RIA) entworfen. Neben der Verwendung im Browser soll auch eine mobile Nutzung möglich sein. Im ersten Schritt wird dabei angenommen, dass Web-Apps als mobile Clients implementiert werden. Die Menge an möglichen Client-Technologien lässt sich somit auf HTML, CSS und JavaScript einschränken. 

Die hier skizzierte Lösung basiert daher auf drei Säulen: 
* Geteiltes CSS
* Geteilte HTML-Templates
* Widgets

Während die erste Säule (Geteiltes CSS) die gemeinsame Nutzung von Design-Elementen und Layout-Beschreibungen erlaubt und somit gemeinsames CD ermöglicht, dient die zweite Säule (Geteilte HTML-Templates) der Implementierung global genutzter User Interfaces (UIs).  So wird in geteilten HTML-Templates eine globale Navigation umgesetzt, zentraler statischer Inhalt verfügbar gemacht (wie bspw. ein Impressum) oder ein Header inkl. Logo für alle Inhalte der RIA bereitgestellt. Diese HTML-Templates beinhalten dabei stets auch Platzhalter für Inhalte, welche durch den jeweiligen Microservice dargestellt werden sollen.

Nachdem die beiden vorherigen Säulen die Nutzung eines globalen User Interfaces erlauben, dienen Widgets der gemeinsamen Nutzung von UI-Elementen durch verschiedene Services. Beispielsweise werden mehrere Services die Auswahl von Nutzern mittels des UI ermöglichen. Neben Herausforderungen hinsichtlich der Wartbarkeit, könnte auch ein CD und die Konsistenz der Nutzerführung nach den gängigen Prinzipien der HCI nicht sichergestellt werden, wenn jeder Service eigene UI-Elemente für diesen Zweck bereitstellen würde. Da Nutzer vom Drops Microservice verwaltet werden, soll dieser auch UI-Elemente zur Verwendung der Nutzer bereitstellen. Nach diesem Prinzip entwickelt, folgt die Architektur auch bezüglich der UI-Elemente den Prinzipien Loosely coupling und High Cohesion, welche für Microservice-Architekturen grundlegend sind.

==== Geteiltes CSS ====
Globales CSS ist im Sinne einer Trennung der Domain nach Bounded Contexts allen Kontexten übergeordnet. Daher ist die Verantwortung für das CSS nicht einem der Microservices zuzuordnen, die funktionale Anforderungen abbilden, sondern separat zu betrachten. CSS wird somit durch den speziellen Microservice Dispenser implementiert, welcher diese nicht-funktionale Anforderung abbildet. 

Das CSS selbst folgt gängigen Richtlinien zur Erstellung modularen CSS (https://css-tricks.com/css-style-guides/ und http://cssguidelin.es/), fungiert als Pattern Library und wird mithilfe von LESS (http://lesscss.org/) entwickelt, um Wartbarkeit und Weiterentwicklung zukunftssicher zu gestalten.

<code><link rel="stylesheet" href="https://pool.vivaconagua.org/dispenser/vca/0.8.4/css/base.min.css"></code>

==== Geteilte HTML-Templates ====
Die Bereitstellung geteilter HTML-Templates erlaubt es den Entwicklern der verschiedenen Microservices die eigenen Inhalte zu fokussieren und reduziert die Aufwände, um die sich wiederholenden HTML Strukturen nachzubauen. Zudem können so Konsistenz und auch Fehlerfreiheit in diesem Bereich sichergestellt werden.

Die Templates werden als Mustache Templates (http://mustache.github.io/) beschrieben und durch den Dispenser Microservice verarbeitet. Microservices können somit ihre Inhalte via Webservice an den Dispenser Service senden, welcher diese Inhalte als Parameter an ein Mustache Template übergibt und das resultierende HTML an den Microservice zurücksendet. Dieser kann dann den HTML-Frame inklusive des eigenen Inhalts ausliefern. Da die Microservices via Webservices Dispenser ansprechen, kann von JSON oder XML als Übertragungsformat ausgegangen werden (auch wenn in diesem Rahmen dringend XML empfohlen wird). Somit ist (relative) Unabhängigkeit von einer speziellen Technologie gewährleistet. Zusätzliche Parametrisierung, um etwa spezielle Seitentitel oder zusätzliches CSS / JS zu erlauben, ist ebenso möglich.

In dem mehrere geteilte HTML-Templates über verschiedene URIs zur Verfügung gestellt werden, ist es möglich unterschiedlichen Organisationen (mit verschiedenen CDs) und Special-Purpose-Pages gerecht zu werden. 

Damit ein HTML-Template und sein jeweiliger Inhalt sich gegenseitig beeinflussen können, wird ein Vorgehen äquivalent zu den Widgets gewählt. Die Kommunikation erfolgt über ein Event-System implementiert in JavaScript (siehe Widgets).

Neben der Zusammenführung von HTML-Templates und Inhalten sowie deren Auslieferung, gibt es weitere implizite Anforderungen, resultierend aus der Idee der HTML-Templates:
* Globale Navigation
* Globaler, statischer Inhalt

===== Globale Navigation =====
Während lokale Navigation in die Inhalte eingebettet werden kann, muss davon ausgegangen werden, dass die globale Navigation innerhalb der HTML-Templates und außerhalb des spezifischen Inhalts eines Microservices abgebildet wird. Eine Abbildung dieser Verantwortung innerhalb der Microservices würde nicht alleine zur Duplizierung von Code und damit erschwerter Wartbarkeit, sondern auch zum Bruch mit dem Prinzip der High Cohesion führen. 

Dem folgend wird die globale Navigation ebenfalls im Dispenser implementiert, aber die Verantwortung der Integration jedem einzelnen Microservice selbst übertragen (Loosely coupling).  Um dies zu erreichen bittet der Dispenser Service alle anderen Services um die Informationen ob und wo im globalen Menü diese erreichbar sein möchten und welcher Entry Point über den Menüeintrag erreicht werden soll. Dafür ruft der Dispenser Service ein RESTful Webservice URI an jedem Microservice auf, welche eine Beschreibung der Integration in Form eines JSON oder XML liefert:

<code>
[
    {
        "hierarchy": ["actions"],
        "link": {
            "label": "Add Actions"
            "link": "https://pool.vivaconagua.org/waves/actions/add"
        },
        "templates": [
            {
                "name": "vca",
                "menu": "main"
            }, 
            {
                "name": "goldeimer",
                "menu": "main"
            }, 
            {
                "name": "acw",
                "menu": "footer"
            }
        ],
        "access-control": ["volunteer-manager", "employee", "admin"]
    },
    {
        "hierarchy": [],
        "link": {
            "label": "Profile"
            "link": "https://pool.vivaconagua.org/drops/user/profile"
        },
        "templates": [
            {
                "name": "vca",
                "menu": "main"
            }, 
            {
                "name": "mineralwasser",
                "menu": "sidebar"
            }, 
            {
                "name": "goldeimer",
                "menu": "main"
            }, 
            {
                "name": "acw",
                "menu": "footer"
            }
        ],
        "access-control": [
            "supporter", "volunteer-manager", "employee", "admin"
        ]
    }
]
</code>

Das gegebene Beispiel zeigt zwei Menüeinträge. Der erste wird in der Hierarchie unter dem Reiter, Tab oder Obermenüpunkt „actions“ eingetragen. Das Wort „actions“ beschreibt dabei einen Platzhalter, der im Dispenser verwendet wird. Die verschiedenen Platzhalter müssen in der Dokumentation zum Dispenser aufgeführt und erläutert werden. Eine mehrstufige Hierarchie zu beschreiben ist ebenfalls möglich, indem die Liste einfach um weitere Platzhalter erweitert wird. Die Position der Platzhalter in der Liste gibt die Ebene der Hierarchie an. Dispenser fügt die Einträge der verschiedenen Microservices zusammen und konstruiert so anhand der Platzhalterpfade jedes Eintrags die Menühierarchie. Der Zweite Menüeintrag ist offenbar keinem Platzhalter oder Pfad untergeordnet und wird daher in der obersten Ebene des Menüs ausgegeben.

Unter „link“ aufgeführte Details beschreiben den Menüeintrag selbst. Dabei wird sowohl der „link“ selbst (also der Ziel-URI), als auch ein „label“, also ein Bezeichner ausgegeben. Zu beachten ist, dass im Sinne des Loosely coupling die Lokalisierung (im Zusammenhang mit Internationalisierung) durch die Microservices selbst übernommen wird. Demzufolge wird unter „label“ bereits der lokalisierte String an den Dispenser übermittelt. Damit die Lokalisierung in diesem Kontext durch den Microservice vorgenommen werden kann, muss der RESTful Webservice URI, den Dispenser aufruft hinsichtlich der Zielkultur paramterisierbar sein.

„templates“ beschreiben in welchen HTML-Templates die Menüeinträge integriert werden sollen und in welchen Menüs in der Oberfläche die Einträge zu finden sind („menu“). Die angegebenen Menünamen müssen dabei dem Dispenser im Kontext des Templates bekannt sein. Daher müssen diese gut dokumentiert sein, ebenso wie die Templates selbst.

Eine Liste von berechtigten Rollen kann zudem unter „access-control“ angegeben werden. Nur Nutzern die die angegebenen Rollen innehaben wird der jeweilige Menüpunkt angezeigt.

Die verschiedenen Microservices, die sich in die globale Navigation integrieren wollen, müssen sich daher beim Dispenser registrieren. Auf diese Weise kann der Dispenser die Services selektieren, die via RESTful Webservice angefragt werden. Nicht registrierte Microservices wünschen keine Integration in ein globales Menü.

===== Globaler, statischer Inhalt =====
Es gibt Inhalte, die für alle Microservices gleich sind und in die geteilten HTML-Templates integriert werden können. Diese Inhalte sollen über einen eigenen Microservice Reservoir erstellt, bearbeitet, gelöscht und ausgeliefert werden. Dieser Microservice integriert sich in die Strukturen von Dispenser, wie zuvor beschrieben, mittels Anschluss an die globale Navigation und der Auslieferung von statischen Inhalten innerhalb der HTML-Templates als Widgets. 

==== Widgets ====
Die Microservices sind mittels Widgets in der Lage einzelne Funktionen inklusive eines UI bereitzustellen, so dass diese durc h andere Microservices ausgegeben werden können.  Ein Widget soll mittels eines URI integriert werden können. Dabei orientiert sich das Konzept der Widgets grundlegend an der Idee von Transclusions. Die bereitstellenden Microservices dienen dabei als Quelle auf welche die URI zeigt. Auf eine GET Anfrage des Widgets mittels des URI liefert der Microservice ein UI-Element zurück, welches dabei jedoch nicht allein statisch ausgegeben werden, sondern auch über dynamisches Verhalten verfügen kann. Neben dem Standardverhalten von HTML-Elementen können auch JavaScript basierte Erweiterungen vorgenommen werden oder vollkommen eigenständige Alternativelemente via JavaScript definiert werden. Hinsichtlich der optischen Präsentation werden Widgets über das geteilte CSS, Style Tags (scoped) innerhalb des  Widget Markups oder das Style-Attribut an den jeweiligen Markup Elementen gestaltet.

Der Aufruf eines Widgets mittels HTTP GET Request liefert immer HTML Code innerhalb eines Root-Tags zurück. Dabei kann der HTML Code eigene(n) CSS oder JavaScript Code enthalten und der Root-Tag frei gewählt werden, muss aber mittels einer ID ausgezeichnet werden, welche das Widget eindeutig identifiziert. Da Widgets gegebenfalls parametrisiert werden müssen (etwa um kontextsensitive Platzhalter für Formular-Elemente zu erlauben), soll die URI die Übergabe von Variablenwerten nach den Kriterien eines RESTful Webservices erlauben. 

Des Weiteren können Widgets Seiteneffekte haben. Diese beschreiben Reaktionen des Widgets auf konkrete Ereignisse.  So kann etwa die Selektion einer Crew in einem Widget A die Auswahl von Nutzern in einem anderen Widget B einschränken. Ereignisse werden über die einbindende Seite mittels JavaScript Events ausgetauscht. Dabei kann ein solcher Event sowohl von der Seite selbst, als auch von einem eingebundenen Widget ausgelöst werden.

Zu jedem Widget muss zusätzlich eine Dokumentation geliefert werden, die mögliche Parametrisierungen, das Verhalten und Seiteneffekte (also die Events auf die reagiert wird) beschreibt. Im Sinne des dezentralen und loosely coupled Organisationsprinzips des Projekts ist definiert, dass Widgets mit Hilfe semantischer Versionierung (http://semver.org/) stets abwärtskompatibel deployed werden. Dies bedeutet, dass die Versionsnummer innerhalb der URI des Widgets spezifiziert werden können muss.

==== Beispiel Widgets ====
Abbildung 1 zeigt eine exemplarische Oberfläche, bereitgestellt vom Waves Microservice. Die gesamte Seite wird dabei durch eine Action in Waves (im Sinne des Model-View-Controller (MVC) Frameworks) generiert, welche über die angesteuerte URL erreichbar ist. Dabei nutzt die Action das geteilte CSS und die geteilten Templates, generiert selber Oberflächen Elemente und Inhalte (z.B. die Input-Felder „Activity name“ oder „Location“) und bindet zusätzliche Widgets vom Drops Microservice ein. Die beiden Widgets aus Drops dienen der Nutzerauswahl (User Selection Widget) und der Auswahl einer verantwortlichen Crew (Crew Selection Widget):

In der ersten Abbildung sind die Widgets zunächst nur durch ihre Oberfläche repräsentiert, die beiden Input-Felder mit den Platzhaltern „Responsible Crew“ und „Responsible Supporter“.  Die Platzhalter zeigen die Notwendigkeit, die dargestellte Oberfläche der Widgets parametrisierbar zu gestalten. In anderen Anwendungsbereichen kann eine andere Beschriftung sinnvoller sein.