Einführung

JS Windows ist ein ECMAScript (JavaScript) basierter Fenstermanager für den Browser, der bis hin zu einer betriebsystemähnlichen Oberfläche erweitert werden kann. Damit bildet JS Windows auch die Grundlage für mein CMS-Projekt. JS Windows selbst verwendet ausschließlich HTML, CSS und ECMAScript. Es ist ohne Server lauffähig, funktioniert also problemlos auch in HTML-Dokumenten, die als einfache Dateien auf dem Computer gespeichert sind.

JS Windows bietet eine Abwärtskompatibilität für Browser, in denen ECMAScript deaktiviert ist. Dafür können direkt im HTML-Code Fenster definiert werden, die ohne ECMA-Script als gewöhnliche Block-Elemente dargestellt werden und mit ECMA-Script beim laden der Seite automatisch in vollwertige, bewegbare Fenster umgewandelt werden.

Es existieren 4 Erweiterungsstufen von JS Windows, die aufeinander aufbauen:

  1. Windows-Only-State: In einfachster Form kann JS Windows ausschließlich zum Erzeugen bewegbarer Fenster auf der Website verwendet werden, quasi als Ersatz zu Popups.
  2. Managed-Windows-State: In diesem Zustand werden die blanken Fenster um eine Taskbar ergänzt. So können problemlos mehrere Fenster vom Benutzer verwaltet werden. Fenster können auch zu Verbänden (Layern) zusammengesetzt werden; ein Fensterverband erzeugt dabei immer ein Taskbarbutton und ist in der Z-Ebene zusammenhängend, also es kann zwischen zwei Fenstern des selben Verbandes kein Fenster eines anderen Verbandes stehen. In diesem Zustand sind auch StayOnTop-Fenster möglich.
  3. JSW-System-State: Dieser Status stellt die Klasse JSWSystem bereit, die automatisch genau ein Mal auf der Website als "jsw" instanziiert wird (Singelton-Pattern). JSWSystem kümmert sich automatisch um die Erstellung des Managers und der Taskbar, bietet vereinfachte Methoden zum Erstellen von Fenstern aus verschiedenen Quellen und ermöglicht auch die Steuerung der Adressleiste oder die Speicherung/Wiederherstellung der offenen Fenster in/von Cookies oder alternativen nicht-flüchtigen Zeichenkettenspeichern. Auf Seiten, die als IFrame in einem Fenster angezeigt werden, muss das Script JSWSystem.js ebenfalls importiert werden; dadurch ist die Instanz jsw dort ebenfalls verfügbar. JSW bietet die Möglichkeit, Module nachzuladen, wie etwa eine Dialogs-Unit. Seiten können so mit wenig Aufwand alert-, prompt- o.ä. Dialoge mit JS Windows anzeigen.
  4. CMS-State: Der CMS-State ist noch nicht fertig, wird aber im wesentlichen dem System-State entsprechen, mit der Besonderheit, dass bestimmte Zusatzunits geladen sein müssen, die den Zugriff auf Dateien auf dem Server bieten. Auch an dieser Stelle möchte ich komplett auf ECMA-Script setzen; es ist mit Hilfe des XMLHttpRequests inzwischen möglich, FTP-Verbindungen zum Server aufzubauen. Auf diese Weise soll auf CGI oder PHP-Applikationen auf dem Server verzichtet werden können. Ein wesentlicher Bestandteil des CMS-States wird eine spezielle Registry, in der Anwendungen ihre Daten speichern können. Diese Registry muss auf viele, kleine Dateien verteilt werden um ebenfalls über FTP abrufbar zu sein. Ich plane dabei ein System, bei dem die Daten der Registry mit unterschiedlichen Root-Keys verschlüsselt sein sollen, welche selber mit dem Passwort des Benutzers verschlüsselt sind. Somit passiert die komplette Entschlüsselung im Browser, was unter Anderem das Ablegen von PGP-Keys in dieser Registry ermöglichen soll.

Abhängigkeiten

Das folgende Klassendiagramm zeigt die Abhängigkeiten zwischen den Klassen und Dateien: