Making-of: Der Web Report Designer in der Entwicklung Teil I

Aktuelle Infos und alle Möglichkeiten zu Web & Cloud Reporting mit List & Label.

Back- und Front-End: Welche Technologien sollen verwendet werden?

Zunächst stand die Frage im Raum, welche Back- und Front-End-Technologien verwendet werden sollten. Für das Back-End haben wir uns für ASP.NET MVC entschieden, da auch der bisherige Web Designer dieses Framework für sein Back-End nutzt. So kann der neue Designer einfach in bestehende Applikationen eingebunden werden. Unterstützt wird das .NET Framework 4.7, .NET Core 3.1 oder auch das neue .NET 5. Und selbstverständlich werden wir mit Release von .NET 6 ab ca. November 2021 auch diese Frameworkversion unterstützen.

Weiterführende Informationen zur Umstellung vom alten Web Designer auf den neuen Web Report Designer (Spoiler: es ist sehr einfach) werden wir in einem späteren Blogpost liefern. Die Voraussetzungen an den Server, auf dem das Back-End gehostet wird, sind gleich geblieben. Das bedeutet, es muss sich um einen Windows Server handeln, auf dem ein IIS installiert ist.

Für das Front-End haben wir React in Kombination mit Bootstrap und Redux verwendet, da wir in diesem Technologiebereich bereits mit dem Report Server sehr positive Erfahrungen gemacht haben.

(zum Vergrößern auf das Bild klicken)

Zu Beginn der Planungen haben wir die wichtigsten Anforderungen an den neuen Web Report Designer definiert: 

• Der Web Report Designer soll auf allen gängigen Browsern lauffähig sein.
• Das Front-End soll in allen gängigen JavaScript Frameworks implementierbar sein.
• Bestehende List & Label Berichte sollen sich im neuen Web Report Designer öffnen lassen.
• Die Oberfläche des Web Report Designers soll auch für Tablets optimiert sein.
• Es soll eine schnelle und einfache Möglichkeit geben, den vorhandenen Code vom alten Web Designer im neuen Web Report Designer zu verwenden.
• Hierbei ist besonders wichtig, dass bestehende Repositories und Datenbankverbindungen ohne großen Aufwand weiter verwendet werden können.

Damit das Front-End so einfach und effektiv wie möglich in bestehende Applikationen eingebaut werden kann, haben wir uns verschiedene Technologien angesehen. Zuerst wurde über eine React-Komponente nachgedacht. Allerdings hätte diese den Nachteil gebracht, dass eine einfache Implementierung in bestehende Angular/Vue-Projekte nicht möglich gewesen wäre. Stattdessen haben wir uns für die Web Components Technologie entschieden. Eine große Hilfe dabei ist Direflow. Dabei handelt es sich um ein Package, welches eine React-Komponente automatisch in eine „Web-Components“-Komponente umwandelt.

Web Components sind einfach gesagt benutzerdefinierte HTML-Elemente, die den eigentlichen Code kapseln. Hierbei werden der HTML-Aufbau inklusive CSS und Javascript gekapselt, um den jeweiligen Code an jeder beliebigen Stelle in einer Webseite oder Web-App verwenden zu können. Die Web Components wurden durch das World Wide Web Consortium (W3C) im Jahr 2012 veröffentlicht. Mittlerweile unterstützen alle gängigen Browser diesen Standard.

Um den neuen Web Report Designer im Front-End Ihrer Anwendung zu integrieren, reicht es, das WebReportDesigner.js einzubinden und anschließend folgenden HTML-Code zu verwenden:

Projektplanung bis ins Detail 

Nach diesen grundsätzlichen Technologieüberlegungen ging es bei der Planung ins Detail. Hierbei wurde der Desktop Designer genau unter die Lupe genommen und eine Liste mit den darin vorhandenen Features erstellt. In dieser Liste wurden den einzelnen Features unterschiedliche Prioritäten zugeordnet, um zu bestimmen, welche unbedingt in der ersten Version enthalten sein sollen. Anschließend wurde die Oberfläche analysiert und geprüft, wie sich diese ins Web übertragen lässt. Hierzu wurde die Oberfläche in einzelne Teilstücke wie die Ribbon-Bar, den Objektbaum, das Eigenschaftenfenster oder den „Variablen/Felder-Datenstrukturbaum“ aufgeteilt. Am Beispiel der Ribbon-Bar wurde dann wie folgt vorgegangen:

Zuerst wurde eine Funktionsanalyse durchgeführt, d.h. es wurde genau definiert, welche Funktionalitäten die einzelnen Komponenten enthalten müssen. Dabei wurde gleich grob abgeschätzt, wieviel Zeit es kosten würde, eine eigene Komponente zu entwickeln. Der Vorteil von selbst geschriebenen Komponenten ist natürlich der komplette Zugriff auf Funktionalität, Design und Wartung.

Parallel wurden bereits bestehende Open Source Projekte – z.B. auf NPM bzw. Github – gesucht, die die benötigten Funktionalitäten enthalten. Generell ist es bei der Auswahl wichtig darauf zu achten, dass die Projekte gepflegt sind. Wir achten hier zum Beispiel darauf, dass die Projekte durch Codeanalyse geprüft und regelmäßige Commits vorhanden sind. Dass es eine breite Basis von Projektmitgliedern gibt und die Projekte eine große Reichweite haben. Außerdem spielt der Support für das Projekt eine wichtige Rolle. Daneben müssen gerade wir als Komponentenhersteller darauf achten, dass sämtliche Lizenzen, die wir in unseren Komponenten hinzufügen, keine besonderen Pflichten für die Weitergabe verlangen. Nur so ist sichergestellt, dass List & Label einfach an Ihre Endkunden weitergegeben werden kann.

Nachdem für die einzelnen benötigten Komponenten jeweils drei Projekte in der engeren Auswahl waren, wurden aus diesen kleine Prototypen entwickelt. In mehreren Projektbesprechungen wurden die Ergebnisse anschließend analysiert – vor allem im Hinblick auf die folgenden Punkte:

• Komplexität
• Wartungsaufwand
• Designmöglichkeiten
• Bedienungsmöglichkeiten – besonders im Hinblick auf mobile Support
• Strategische Bedeutung – wie schlimm wäre es, wenn die Komponente von heute auf morgen nicht mehr funktionieren würde

Dagegen wurde der Aufwand abgewogen, Bereiche mit selbst geschriebenen Komponenten abzudecken. So wurde dann z.B. entschieden, dass wir kein klassisches „Ribbon-Menü“ verwenden wollen, da dieses auf mobilen Geräten nur sehr schwer bedient werden kann. Gerade für diesen Bereich war die Komplexität, eine eigene Komponente zu schreiben, nicht besonders hoch.

Für andere Bereiche setzen wir dagegen auch auf Open Source-Komponenten:

• Drag & Drop
• State-Verwaltung
• Abfrage Back-End-API
• Hotkeys
• Color-Picker
• Editor

Nachdem wir die einzelnen Teilstücke analysiert hatten, wurden daraus die ersten UI-Mockups gebaut.

Entwicklung des Layouts

Im nächsten Schritt wurde dann mit der Entwicklung des „Basis“-Layouts des Web Report Designers begonnen. Hierzu wurde eine Solution-Struktur angelegt, die zum größten Teil auf der Standard-Vorgehensweise von React-Webseiten beruht. Dieser Aufbau sieht wie folgt aus:

• Bei den „assets“ handelt es sich um alle benötigen CSS-Stylesheets wie z.B. Bootstrap.
• Bei den „components“ handelt es sich um wiederverwendbare Komponenten, die im gesamten Designer genutzt werden können wie z.B. der „Formeleditor“, „Navigations“-Komponenten, „Popup-Modals/Dialoge“ aber auch die verschiedenen „TreeView“-Komponenten.
• Bei den „helper“ handelt es sich um Helperfunktionen, die im Designer benötigt werden wie z.B. Funktionen zum Umrechnen der List & Label Einheiten, für Datumsvariablen, für Farbeinstellungen aber auch für die Typenumwandlung in Typescript
• „hooks“: Hier wurden diverse hooks geschrieben, die uns einen einfachen Zugriff auf unseren Redux Store erlauben. Als Beispiel haben wir eine Hook „useReportParameters“, um einfach in Komponenten auf die aktuellen Berichtsparameter im Projekt zugreifen zu können:​

(zum Vergrößern auf das Bild klicken)

• „layouts“: Hier wurden die einzelnen Container für die verschiedenen Aufgaben im Web Report Designer angelegt – dazu wurde der Web Report Designer in einzelne „Layout“-Bestandteile aufgeteilt:

(zum Vergrößern auf das Bild klicken)

1: „ObjectMenuBarSection“
2: „DesignSpaceSection“
3: „TopMenuBarSection“
4: „ToolsPanelSection“

• „models“: Hier werden alle Interfacedefinitionen für die Kommunikation mit dem Back-End bereitgestellt.
• „pages“: Hierbei handelt es sich um einzelne Komponenten, die einen bestimmten Zweck erfüllen und nicht so weit generalisiert werden konnten, dass sie flexibel verwendbar sind wie z.b. „BackstageViews“ oder bestimmte „Eigenschafts“-Editoren.
• „service_callbacks“ und „services“: Hierbei handelt es sich um Funktionen die den Store modifizieren („services“) oder eine Kommunikation mit dem Back-End übernehmen („service_callbacks“)
• „store“: Hier werden die unterschiedlichen Redux Store Definitionen gespeichert. Dieser ist wieder unterteilt in kleinere „Unter“-Stores um den Überblick zu behalten:

Unsere weitere Vorgehensweise und die Herausforderungen die dabei aufgetreten sind – vor allem in Hinblick auf „Drag & Drop“, „State-Verwaltung“, „Back-End-Anfragen“, „Hotkeys“ und „Editor“, erfahren Sie in Kürze im zweiten Teil.