erwartende Veränderungen vorgenommen werden, sondern auch, um externe Hinzufügungen zu integrieren. Hin und wieder ist ein vollständiger Compare-Editor mit linker und rechter Seite notwendig, wie man ihn von Eclipse kennt. Auch hierfür stellt die Seite die notwendigen Links bereit.
Abbildung 2.3: Source Control
Unterschiede, die die Fähigkeiten und Herangehensweisen der Source-Control-Managementwerkzeuge betreffen, sind von Bedeutung. Die Git-Statusseite ist Git-spezifisch, und obwohl Komponenten wie der Compare-Editor wiederverwendet werden können, ist die Seite selbst kaum für Erweiterungen geeignet. Wir haben mit der Eclipse-Plattform die Erfahrung gemacht, dass es keineswegs ideal ist, Source-Control-Support zu verallgemeinern. Am besten integriert man ein neues Source-Control-Werkzeug über eine neue Task-Seite.
User Experience in Orion ist ein Dauerbrenner. Obwohl mit dieser Seite vieles möglicht wird, ist sie uns noch etwas zu komplex. Orion soll nicht nur in Desktopbrowsern betrieben werden, sondern auch auf mobilen Geräten wie Tablets. Diesbezüglich wird sich auf dem Weg zur ersten Major Release wohl noch einiges tun. Es soll aber auch nicht unerwähnt bleiben, dass das Orion-Team seit nunmehr sechs Monaten selbst hostet, also Orion selbst verwendet, um es weiter zu entwickeln – eine Zeit, in der die Funktionalität dieser Seite zu einem Schlüsselkonzept und gleichsam zu einem Zeichen von Qualitätsarbeit geworden ist.
2.3 Die Architektur: ein Überblick
Im ersten Teil des Kapitels wurden Designstrategien und einige der Task-Seiten in Orion besprochen und technische Details ausgespart. Orion ist eine Webapplikation, umfasst also sowohl einen Client als auch einen Server. Der Orion-Client ist in reinem HTML, CSS und JavaScript geschrieben und kann auf jedem Standardwebserver gehostet werden. Der Orion-Server ist, was wenig erstaunen dürfte, Java-basiert und wurde unter Verwendung von Equinox-Servertechnologien aufgebaut. Der Orion-Client – wie erwähnt in HTML, CSS und JavaScript – macht keinerlei Gebrauch von Server-Templates oder dynamischen Inhalten. In unserer UI verwendet er Dojo, RequireJS für unsere Komponenten und ist relativ offen für HTML5-Technologien. Deswegen müssen Nutzer über das verfügen, was gemeinhin als „Moderner HTML5-Browser“ bezeichnet wird; jeder der aktuell gängigen Browser ist geeignet. Da Orion dafür bestimmt ist, von Seiten des Clients erweitert zu werden, zeichnet er sich durch eine neue Art von Plug-in aus.
Modularität
Betrachtet man die JavaScript-Dateien in Orion, so sieht man, dass jedes Skript in eine define() -Funktion eingepackt ist. JavaScript-Komponenten in Orion verwenden, wie bereits erwähnt, RequireJS [2] als Bibliothek. Diese implementiert Asynchronous Module Definition (AMD), um Abhängigkeiten zu verwalten. RequireJS stellt sicher, dass Skripte in korrekter Reihenfolge geladen werden und unterstützt zudem Performanceverbesserungen wie das parallele Herunterladen von Skripten. Durch die Verwendung von AMD werden Namespacing-Probleme umgangen. Zudem stehen Metadaten zur Verfügung, um die Komponenten zu analysieren. Um ein konkretes Beispiel zu nennen: Wenn man die Komponentenabhängigkeitsbäume durchgeht, lassen sich die notwendigen Skripte für eine Seite in einer einzigen Datei kombinieren, das Resultat also verkleinern, um eine höhere Ladeperformance zu erzielen.
Erweiterbarkeit
Ein Knackpunkt bei der Verwendung von Modularität in Orion ist der, dass JavaScript-Komponenten von anderen Seiten niemals dynamisch auf unsere Seiten geladen werden. Beliebigen Quellcode von externen Seiten zu laden ist keine besonders sichere Art, eine Webanwendung zu erweitern und würde Orion ein weites Feld an Sicherheitsproblemen bescheren. Die bereits erwähnte besondere Art des Plug-ins, die bei Orion verwendet wird, nutzt die browsereigene Sicherheit, um die Implementierung des Plug-ins von der Host-Seite zu isolieren. Ein Orion-Plug-in ist ein HTML-Dokument, das üblicherweise keine Benutzerschnittstelle hat, sondern in einem
Kostenlos Online Lesen 