Wir werden mit einem Blick auf die Handhabung von XUL in Mozilla starten.
Wie wird XUL behandelt
In Mozilla wird XUL genauso behandelt wie HTML oder anderer Inhalt. Wenn man die URL einer HTML-Seite in das Adressfeld des Browsers eingibt, ortet der Browser die Webseite und lädt den Inhalt herunter. Die Mozilla Rendering-Engine übersetzt den HTML-Quelltext in ein Dokumentbaum mit DOM. Anschließend wird der Baum in ein Satz Objekte konvertiert, die am Bildschirm angezeigt werden können. CSS, Bilder und andere Technologien werden verwendet, um die Anzeige zu kontrollieren. XUL funktioniert größtenteils auf die selbe Art und Weise.
In der Tat werden alle Dokumenttypen, egal ob HTML, XUL oder sogar SVG, durch den selben zugrunde liegenden Code behandelt. Das bedeutet, dass die selben CSS-Eigenschaften benutzt werden können, um sowohl HTML und XUL zu manipulieren. Daher können viele Funktionen von beiden genutzt werden. Doch gibt es einige Funktionen, welche nur von HTML verwendet werden können, wie z.B. Formulare, und andere, welche nur von XUL verwendet werden können, so wie Overlays. Da XUL und HTML auf die selbe Art und Weise behandelt werden, kann man beide, sowohl vom lokalen Dateisystem, von einer Webseite oder von einer Erweiterung oder einer selbständigen XULRunner-Anwendung laden.
Inhalte aus entfernten Quellen z.B. https://localhost/~username/ sind (egal ob HTML, XUL oder ein anderer Dokumententyp) aus Sicherheitsgründen in ihrem Handlungsspielraum beschränkt. Deshalb stellt Mozilla die Methode zur Verfügung, Inhalte lokal zu installieren und registriert die installierten Dateien in sein chrome-System. Dies ermöglicht, dass eine spezielle URL-Form genutzt werden kann, die chrome:// URL genannt wird. Durch den Zugriff auf eine Datei mittels einer Chrome-URL erhält die Datei höhere Rechte, um auf lokale Dateien, Eigenschaften und Bookmarks zuzugreifen und andere privilegierte Operationen auszuführen. Webseiten erhalten diese Privilegien nicht, es sei denn sie sind mit einem digitalen Zertifikat signiert, und der Benutzer hat den Zugriff auf diese Operationen gewährt.
Die chrome-Paketregistrierung ist der Weg, um es Firefox-Erweiterungen zu ermöglichen, Funktionen zum Browser hinzuzufügen. Erweiterungen sind kleine Pakete mit XUL-Dateien, JavaScript, Stylesheets und Bildern, die in einer einzigen Datei verpackt sind. Eine solche Datei kann mit einem ZIP-Programm erstellt werden. Wenn der Benutzer diese Datei herunterlädt, wird die Erweiterung auf seiner Maschine installiert. Sie hängt sich in den Browser ein, indem sie eine XUL-Eigenschaft benutzt, die man Overlay nennt. Sie erlaubt es, das XUL der Erweiterung mit dem XUL des Browsers zu kombinieren. Für den Benutzer scheint es, als ob die Erweiterung den Browser verändert hat, aber in Wirklichkeit ist der Quelltext separat und die Erweiterung kann leicht entfernt werden. Registrierte Pakete müssen natürlich nicht unbedingt Overlays benutzen. Wenn sie keinen Gebrauch von Overlays machen, ist die Erweiterung nicht von der Browser-Oberfläche aus erreichbar, aber man kann sie über die Chrome-URL erreichen, sofern das erwünscht ist.
Eigenständige XUL-Anwendungen können XUL-Code auf ähnliche Weise enthalten, er wird aber natürlich als Teil der Installation eingebunden, anstatt separat als Erweiterung eingebettet zu werden. Dennoch wird der XUL-Code im chrome-System registriert, sodass die Applikation die Benutzeroberfläche darstellen kann.
Der Mozilla Browser selbst ist ebenfalls nichts weiter als eine Sammlung von Paketen, die XUL-Dateien, JavaScript und Stylesheets enthalten. Diese Dateien können über die chrome URL erreicht werden, haben erweiterte Privilegien und verhalten sich auch sonst wie andere Pakete. Natürlich ist der Browser weitaus größer und komplexer als die meisten Erweiterungen. Firefox und Thunderbird und einige andere Komponenten sind alle in XUL geschrieben und erreichbar über chrome-URLs. Sie können diese Pakete erkunden, indem Sie die Dateien in dem chrome-Verzeichnis ansehen, wo Firefox oder die anderen XUL-Anwendungen installiert sind.
Die chrome-URL beginnt immer mit 'chrome://'. Ähnlich wie eine 'https://'-URL immer eine entfernte Website per HTTP adressiert und die 'file://'-URL immer lokale Dateien, referenziert die 'chrome://'-URL immer installierte Pakete und Erweiterungen. Wir werden uns die chrome-Syntax im nächsten Kapitel genauer ansehen. Es ist wichtig zu wissen, dass der Zugriff über eine chrome-URL erweiterte Privilegien gegenüber den anderen Arten von URLs erlangt. Beispielsweise hat eine HTTP-URL keine besonderen Rechte und es wird ein Fehler ausgegeben, wenn eine Website versucht, zum Beispiel lokale Dateien zu lesen. Wird hingegen eine Datei von einer chrome-URL aus geladen, hat sie das Recht, lokale Dateien ohne Einschränkungen zu lesen.
Diese Unterscheidung ist wichtig. Es bedeutet, dass Websites bestimmte Dinge nicht tun können, wie zum Beispiel die Lesezeichen des Benutzers zu lesen. Diese Unterscheidung basiert nicht auf dem Inhalt, sondern nur auf der URL, die benutzt wird. Sowohl HTML als auch XUL auf einer Website haben keine erweiterten Rechte, wohingegen XUL und HTML, die mit einer chrome-URL geladen wurden, erweiterte Privilegien haben.
Wenn Sie XUL auf einer Website benutzen möchten, müssen Sie nur die XUL-Dateien auf die Website stellen, genau so, wie Sie es auch mit HTML-Dateien tun. Laden Sie dann die URL in den Browser: https://localhost/xul.php. Vergewissern Sie sich, dass Ihr Webserver so konfiguriert ist, dass er XUL-Dateien mit dem passenden Content-Type application/vnd.mozilla.xul+xml ausliefert. (zum Beispiel mittels PHP: header('content-type: application/vnd.mozilla.xul+xml');). Der Content-Type stellt sicher, dass Mozilla HTML und XUL unterscheiden kann. Mozilla nutzt die Dateierweiterung nur, solange die Datei vom Dateisystem gelesen wird. Sie sollten trotzdem die .xul-Dateiendung für all Ihre XUL-Dateien benutzen. Sie können XUL-Dateien in Ihren Browser laden, indem Sie sie mit dem Browser öffnen oder im Datei-Manager die Datei doppelklicken.
Dokumenttypen: HTML XML XUL CSS
Mozilla verwendet deutlich unterschiedliche Arten des Dokumentenobjektmodells (DOM) für HTML und XUL, obwohl viele der Funktionen gemeinsam verwendet werden. Es gibt drei hauptsächliche Dokumententypen in Mozilla: HTML, XML und XUL. Natürlich wird HTML für HTML-Dokumente genutzt, XUL für XUL-Dokumente und XML für andere XML-Dokumenttypen. Da XUL ebenfalls XML ist, ist das XUL-Dokument als eine Unterart des XML-Dokumentes zu verstehen. Es gibt feine Unterschiede in der Funktionsweise. Zum Beispiel sind die Formularsteuerungen auf einer HTML-Seite über die document.forms-Eigenschaft erreichbar, während diese nicht für XUL-Dokumente verfügbar ist, weil XUL keine Formulare im Sinne von HTML haben. Andererseits sind spezielle XUL-Funktionen (wie Overlays und Templates) nur in XUL-Dokumenten verfügbar.
Diese Unterscheidung zwischen den Dokumenten ist wichtig. Es ist möglich viele XUL-Funktionen in HTML oder XML-Dokumenten zu verwenden, sofern sie nicht spezifisch für den jeweiligen Dokumententyp sind. Andere Funktionen erfordern jedoch den richtigen Dokumententyp. Daher können Sie zum Beispiel XUL-Layouts in anderen Dokumenten verwenden, da diese nicht vom XUL-Dokumententyp abhängig sind.
Um die oben genannten Punkte zusammenfassen:
- Mozilla rendert sowohl HTML als auch XUL mit der gleichen zugrunde liegenden Engine und verwendet CSS, um das Aussehen festzulegen.
- XUL kann von einer entfernten Seite, vom lokalen Dateisystem oder als Paket installiert und über eine chrome-URL erreicht werden. Von der letzten Möglichkeit machen Erweiterungen gebrauch.
- Chrome-URLs können verwendet werden, um auf installierte Pakete zuzugreifen und sie mit erweiterten Privilegien zu öffnen.
- HTML, XML und XUL haben alle einen unterschiedlichen Dokumententyp. Einige Funktionen können in jedem Dokumententyp verwendet werden, während andere einen bestimmten Typ erfordern.
Die nächsten Abschnitte beschreiben die grundlegende Struktur eines Chrome-Pakets, welches in Mozilla installiert werden kann. Wenn Sie jedoch beginnen wollen eine einfache Anwendung zu schreiben, sollten Sie zu "Ein Fenster erzeugen" springen und zu diesem Abschnitt später zurück kommen.
Paketorganisation
Mozilla ist so organisiert, sodass Sie so viele Komponenten wie Sie möchten, vorinstallieren können. Jede Erweiterung ist eine eigenständige Komponente mit einer separaten Chrome-URL. Mozilla verfügt außerdem über je eine Komponente für jedes installierte Theme und Sprachpaket. Jedes dieser Komponenten oder Pakete besteht aus einer Reihe von Dateien, welche die Benutzeroberfläche dafür beschreiben. Die Messenger-Komponente besitzt z.B. Beschreibungen für Fenster von Mailnachrichten oder Adressbuchdialogen.
Die Pakete, die mit Mozilla ausgeliefert werden, befinden sich im Chrome-Verzeichnis, welches das Verzeichnis ist, wo Sie Mozilla installiert haben. Das Chrome-Verzeichnis ist das, wo Sie alle Dateien, die die Benutzeroberfläche beschreiben, finden. Normalerweise packen Sie alle XUL-Dateien für eine Anwendung in dieses Verzeichnis, obwohl Erweiterungen in das Erweiterungsverzeichnis für einen bestimmten Benutzer installiert werden. Das einfache Kopieren einer XUL-Datei in das chrome-Verzeichnis gibt der Datei noch keine erweiterten Rechte und außerdem kann sie nicht über eine chrome-URL aufgerufen werden. Um diese zusätzlichen Privilegien zu bekommen, müssen Sie eine Manifestdatei erstellen und diese in das Chrome-Verzeichnis packen. Diese Datei ist sehr einfach zu erstellen und ist normalerweise nur ein paar Zeilen lang. Diese Datei wird verwendet, um chrome-URLs auf eine Datei oder einen Verzeichnispfad zu binden, wo sich die XUL-Dateien befinden. Details zur Erstellung dieser Datei werden in einem späteren Abschnitt genauer betrachtet.
Der einzige Weg Inhalte zu erstellen, die über eine Chrome-Url erreichbar sind, ist, ein Paket wie in nächsten Abschnitten beschrieben, zu erstellen. Das Verzeichnis wird 'chrome' genannt, weil es ein geeigneter Name zur Aufbewahrung von Chrome-Paketen ist, welche in Mozilla enthalten sind.
Um die Verwirrung noch weiter zu treiben, gibt es noch zwei weitere Orte, wo das Wort "chrome" auftreten könnte. Das ist einmal das -chrome-Kommandozeilenargument und zum anderen der chrome-Modifier der window.open()-Funktion. Keine dieser Funktionen verteilen zusätzliche Privilegien, stattdessen werden sie verwendet, um ein neues Top-Level-Fenster ohne das Browser UI (Toolbars, Menü) zu erstellen. Sie werden diese Funktion sicher noch in komplexeren XUL Anwendungen verwenden, wenn Sie nicht das Browser UI um Ihre Dialogboxen herum haben wollen.
Dateien eines Pakets werden normalerweise in einzelne JAR-Dateien zusammengefügt. Eine JAR-Datei kann mit einem ZIP-Tool erstellt werden. Beispielsweise können Sie JAR-Dateien in Mozilla's chrome-Verzeichnis öffnen, um die grundlegende Struktur des Pakets zu sehen. Obwohl es normal so ist, dass die Dateien in einer JAR-Datei gepackt sind, können Pakete genauso von einem normalen Verzeichnis erreicht werden. Obwohl Pakete normalerweise nicht auf diese Art ausgeliefert werden, ist es dennoch während der Entwicklung handlicher, die Dateien vorerst nicht zu packen, da Sie diese dann besser bearbeiten können ohne die Dateien jedes Mal neu zu packen zu müssen.
Standardmäßig parsen Mozilla-Applikationen XUL-Dateien und Skripte und speichern eine vor-kompilierte Version im Speicher im Laufe der Anwendungssitzung. Das verbessert die Leistung. Dadurch wird XUL allerdings nicht neu geladen, auch nicht, wenn die Quelldateien sich geändert haben. Um diesen Mechanismus zu deaktivieren, ist es notwendig die Einstellung nglayout.debug.disable_xul_cache festzulegen. In Firefox muss diese Einstellung unter Umständen hinzugefügt werden, indem "about:config" in die Adresszeile eingegeben wird und dieser Wert auf "true" gesetzt wird. Oder Sie verändern die user.js-Einstellungsdatei manuell und fügen die folgende Zeile hinzu:
pref("nglayout.debug.disable_xul_cache", true);
Es gibt normalerweise drei verschiedene Teile eines chrome-Pakets, auch wenn sie alle optional sind. Jeder Teil wird in einem anderen Verzeichnis gespeichert. Diese drei Sets sind content, skin und locale, welche unten näher beschrieben sind. Ein bestimmtes Paket kann ein oder mehrere Skins und Sprachen bereitstellen und der Benutzer kann diese mit den eigenen ersetzen. Zusätzlich kann das Paket mehrere unterschiedliche Anwendungen enthalten, jedes davon über eine andere chrome-URL erreichbar. Das Paketsystem ist flexibel genug, um separate Downloads von anderen Teilen wie zum Beispiel andere Sprachen, handzuhaben.
Die drei Typen der Chrome-Pakete sind:
- Content - Fenster und Skripte
Beinhaltet Festlegungen zu Fenstern und der Benutzeroberfläche. Diese sind in XUL-Dateien gespeichert, welche eine.xul-Endung haben. Ein content-Paket kann mehrere XUL-Dateien besitzen, aber das Hauptfenster sollte den gleichen Dateinamen haben, wie die Anwendung selbst. Beispielsweise sollte ein "Editor"-Paket die Dateieditor.xulhaben. Skripte werden in separaten Dateien neben den XUL-Dateien platziert. - Skin - Style Sheets, Bilder und andere Dateien zum Aussehen
Style Sheets beschreiben Details zum Erscheinungsbild eines Fensters. Sie werden separat von den XUL-Dateien gespeichert, um Änderungen am Aussehen einfacher verwalten zu können. Etwaige Bilder werden hier ebenfalls gespeichert. - Locale - Dateien zum Text und zur Sprache
Der gesamte Text, welcher in der Anwendung angezeigt wird, wird hier gespeichert. Dadurch wird ermöglicht, dass der Benutzer eine eigene Sprache für das Paket bereitstellen kann.
Content Pakete
Der Name der JAR-Datei kann beschreiben, was sich darin befindet, aber Sie können nur sicher gehen, wenn Sie sich die Inhalte wirklich anschauen. Verwenden wir das Browserpaket, welches in Firefox enthalten ist als Beispiel. Wenn Sie Dateien in browser.jar entpacken, werden Sie die folgende Verzeichnisstruktur auffinden:
content
browser
browser.xul
browser.js
-- weitere XUL und JS-Dateien --
bookmarks
-- Bookmarks-Dateien --
preferences
-- Einstellungsdateien --
.
.
.
Das lässt einfach als ein 'content'-Paket identifizieren, weil das oberste Verzeichnis "content" genannt wurde. Für Skins wird dieses Verzeichnis normalerweise "skin" und für Sprachen wird es normalerweise "locale" genannt. Dieses Benennungsschema ist nicht notwendig, aber es ist eine gute Konvention, um die Teile des Pakets klar trennen zu können. Einige Pakete können unter Umstand ein Abschnitt für content, skin sowie locale besitzen. In diesem Fall werden Sie ein Unterverzeichnis für jeden Typ finden. Chatzilla wird zum Beispiel auf diesem Weg ausgeliefert.
Das "content/browser"-Verzeichnis enthält eine Vielzahl an Dateien mit der Endung .xul und .js. Die XUL-Dateien sind die mit der .xul-Endung. Die Dateien mit der .js-Endung sind JavaScript-Dateien, welche Skripte enthalten, die die Funktionen eines Fenstern steuern. Viele XUL-Dateien haben eine zugehörige JavaScript-Datei und einige haben sogar mehr als eine.
In der Verzeichnisauflistung oben werden zwei Dateien genannt. Es gibt natürlich noch weitere, aber zur Einfachheit wurde diese ausgelassen. Die Datei browser.xul ist die XUL-Datei, die das Hauptfenster beschreibt. Das Hauptfenster für ein "content"-Paket sollte den selben Namen wie das Paket haben, mit der Endung .xul. In diesem Fall ist der Paketname "browser" also erwarten wir die Datei browser.xul. Einige der anderen XUL-Dateien beschreiben weitere Fenster. Die Datei pageInfo.xul beschreibt zum Beispiel den Seiteninformationsdialog.
Viele Pakete werden eine contents.rdf Datei enthalten, welches das Paket beschreibt, den Autor und die Overlays, die verwendet werden. Diese Datei ist jedoch veraltet und wurde durch ein einfacheres Verfahren ersetzt. Die neue Methode ist die sogenannte Manifestdatei, die bereits erwähnt wurde. Diese Dateien finden Sie mit der Endung .manifest im Chrome-Verzeichnis. Die Datei browser.manifest beschreibt beispielsweise das Browser-Paket.
Mehrere Unterverzeichnisse wie "bookmarks" und "preferences" sind zusätzliche Bereiche der Browser-Komponente. Sie werden nur in unterschiedlichen Ordnern aufbewahrt, um die Dateien besser organisieren zu können.
Skins oder Themes
Obwohl der zugrunde liegende Code für Mozilla sie Skins nennt und die Benutzeroberfläche den Ausdruck "Themes" gebraucht, meinen beide die gleiche Sache. Die classic.jar-Datei beschreibt das Standard-Theme von Firefox. Die Struktur ist ähnlich zum content-Paket. Zum Beispiel classic.jar:
skin
classic
browser
browser.css
-- weitere browser Skin-Dateien --
global
-- globale Skin-Dateien --
.
.
.
Auch hier ist die Verzeichnisstruktur nicht notwendig und wird zur besseren Organisation verwendet. Sie können sogar alle Dateien in ein Verzeichnis packen. Für große Anwendungen werden Unterverzeichnisse verwendet, um verschiedene Komponenten zu trennen. Im obigen Beispiel existiert ein Verzeichnis für Theme-bezogene Dateien des Browsers und ein Ordner für globale Theme-bezogene Dateien. Das "global"-Verzeichnis enthält Skin-Dateien, die allgemein für alle Pakete zu gebrauchen sind. Die Dateien sind für alle Komponenten angelegt und werden mit ihrer eigenständigen Anwendung eingebunden. Der globale Teil definiert den Teil der gemeinsamen XUL-Widgets, wohingegen die anderen Verzeichnisse Dateien enthalten, die speziell für die entsprechenden Anwendungen sind. Firefox bindet beide, die globalen und die Browser Theme-Dateien in einem Archiv ein, aber sie können auch einzeln eingebunden werden.
Ein Skin besteht aus CSS-Dateien und einer Reihe von Bildern, die das Aussehen des Interface definieren. Die Datei browser.css wird von browser.xul verwendet und enthält Styles, welche das Aussehen unterschiedlicher Teile der Anwendung beschreiben. Beachten Sie hier wieder, dass die Datei browser.css den gleichen Dateinamen wie das Paket besitzt. Beim Verändern von CSS-Dateien, stellen Sie das Aussehen eines Fensters ein, ohne dabei die Funktionen zu beeinflussen. Auf diese Weise können Sie ein neues Theme erstellen. Der XUL-Teil bleibt der Gleiche, aber der Skin-Teil wird unabhängig verändert.
Lokalisierung
Die Datei "en-US.jar" beschreibt die Sprachinformationen für jede Komponente, in diesem Fall für US-Englisch. Wie bei den Skins, enthält jede Sprachdatei Dateien, welche den Text für das Paket in der jeweiligen Sprache festlegen. Die Struktur von "locale" ist ähnlich zu den anderen, wir werden das hier nicht noch einmal auflisten.
Der lokalisierte Text wird in zwei verschiedenen Dateitypen gespeichert: DTD-Dateien und properties-Dateien. Die DTD Dateien haben die Endung .dtd und enthalten Entity-Deklarationen, eine für jeden Textstring, welcher in einem Fenster verwendet wird. Die Datei browser.dtd enthält zum Beispiel Entity-Deklarationen für jedes Menü-Kommando. Zusätzlich werden Tastaturkürzel für jedes Kommando definiert, weil Sie eventuell unterschiedlich in verschiedenen Sprachen sein können. DTD-Dateien werden von XUL Dateien benutzt, meist werden Sie eine Datei pro XUL Datei finden. Der "locale" Teil beinhaltet auch "properties" Dateien, welche ähnlich sind, aber von Skriptdateien verwendet werden. Die Datei browser.properties enthält einige solcher lokalisierter Strings.
Diese Struktur erlaubt Ihnen Mozilla oder eine Komponente in verschiedene Sprachen zu übersetzen, in dem einfach ein neues "locale"-Verzeichnis hinzugefügt wird. Sie müssen den XUL-Code gar nicht verändern. Weiter kann eine andere Person ein anderes Paket hinzufügen, welches Unterstützung für eine neue Sprache bietet, ohne dass Ihr Originalpaket verändert wird.
Weitere Pakete
Es gibt ein spezielles Paket, welches "Toolkit" (oder "global") genannt wird. Wir haben uns das "global"-Verzeichnis für Skins angeschaut. Die Datei toolkit.jar enthält den zugehörigen "content"-Teil dazu. Es sind einige globale Dialoge und Definitionen darunter. Es wird auch das Standardaussehen und die Standardfunktionen der XUL-Widgets, wie Textboxen und Schaltflächen festgelegt. Diese Datei im globalen Teil eines Skin-Verzeichnisses enthalten das Standardaussehen für alle XUL Interface-Elemente. Das Toolkit-Paket wird von allen XUL-Applikationen verwendet.
Ein Paket hinzufügen
Mozilla platziert die Pakete, die mit der Installation eingebunden werden, in das Chrome-Verzeichnis. Diese Dateien müssen dort jedoch nicht platziert werden. Wenn ein anderes Paket installiert wird, können Sie dies überall auf der Festplatte platzieren, so lange eine Manifestdatei darauf zielt. Es ergibt Sinn Pakete in das Chrome-Verzeichnis zu packen, einfach weil es bequemer ist. Jedoch funktionieren die Pakete genauso gut, wenn sie woanders liegen. Sie können die Dateien jedoch nicht auf einer entfernten Seite speichern, da die entfernte Seite nicht durch das lokale Dateisystem gemountet ist.
Es gibt zwei chrome-Verzeichnisse für XUL-Applikationen: Eine ist dort installiert, wo auch die Anwendung installiert wurde, während die andere Teil des Benutzerprofils ist. Das erste Verzeichnis erlaubt Paketen über alle Benutzer zu agieren, während das zweite Verzeichnis nur für den jeweiligen Benutzer erstellt worden ist. Erweiterungen werden in einem separaten Erweiterungsverzeichnis installiert und sind außerdem Benutzer-spezifisch. Jede Manifestdatei in einem der Chrome-Verzeichnissen wird geprüft, um zu sehen, welche Pakete installiert sind.
Im nächsten Abschnitt werden wir einen Blick darauf werfen, wie man die Chrome-URL verwendet, um sich auf Chrome-Pakete zu beziehen.