Écrit par Neil Deakin.
Traduit par Romain D. (11/02/2004), mise à jour par Laurent Jouanneau (22/11/2004) .
Page originale :
http://www.xulplanet.com/tutorials/xultu/chromeurl.html
La section suivante décrira comment se rapporter à des documents XUL et autres fichiers Chrome.
Les fichiers XUL peuvent être référencés par un URL HTTP habituel tout comme les fichiers HTML (ou tout autre type d'URL). Cependant, les paquetages qui sont installés sur le système chrome de Mozilla peuvent être référencés avec des URLs spéciaux "chrome". Les paquetages livrés avec Mozilla seront déjà installés mais vous pouvez déclarer les vôtres.
Les paquetages installés ont l'avantage de ne pas avoir de restrictions de sécurité, lesquelles sont nécessaires pour de nombreuses applications. Un autre avantage comparé aux autres types d'URLs est qu'ils manipulent automatiquement les thèmes (NdT : skins) et localisations (NdT : locales). Par exemple, un URL chrome vous permet de vous référer à un fichier dans le thème, comme une image, sans avoir besoin de savoir quel thème l'utilisateur utilise. Tant que les noms de fichiers sont les mêmes dans chaque thème, vous pouvez vous référer à un fichier en utilisant un URL chrome. Mozilla fera attention pour déterminer où le fichier est situé et renverra la bonne donnée. Cela signifie aussi que l'endroit où le paquetage est installé n'est pas important pour être capable d'y accéder. Les URLs chrome sont indépendantes du lieu où les fichiers sont stockés physiquement. Cela est plus facile pour écrire des applications qui ont beaucoup de fichiers puisque vous n'avez pas à vous inquieter sur les détails des chemins des fichiers.
La syntaxe de base d'un URL chrome est la suivante :
chrome://<paquetage>/<partie>/<fichier.xul>
<paquetage>
est le nom du paquetage, tel que messenger ou editor.
Le <partie>
vaut soit content, soit skin ou locale,
selon la partie que vous voulez. fichier.xul
est simplement le nom du fichier.
Exemple : chrome://messenger/content/messenger.xul
Ici, l'exemple se réfère à la fenêtre messenger. Vous pouvez pointer vers un fichier qui fait parti d'un thème en remplaçant content par skin et en changeant le nom du fichier. De même, vous pouvez pointer vers un fichier qui fait parti de la localisation en utilisant locale au lieu de content.
Quand vous ouvrez un URL chrome, Mozilla regarde à travers sa liste de paquetages installés et essaie
de trouver le fichier JAR qui correspond au nom et à la partie. Une fois trouvé, il regardera dans ce fichier
JAR si il y a fichier.xul
. Mozilla commencera toujours par regarder dans le répertoire
dans le fichier JAR
où le fichier contents.rdf associé, décrit dans la section précédente, se trouve. Cela signifie que si
plusieurs paquetages ou parties sont tous situés dans le même fichier JAR, les fichiers seront localisés
à la bonne place. Par exemple, le fichier contents.rdf pour l'URL chrome de messenger est situé dans le fichier
messenger.jar et à l'interieur de l'archive, dans le répertoire 'content/messenger'. Cela signifie que le fichier
messenger.xul sera chargé à partir de cet endroit, et si vous ouvrez le fichier messenger.jar, vous trouverez
ce fichier dans ce répertoire. Si vous utilisez une forme décompressée plutôt qu'une archive JAR, la même chose
s'applique excepté que Mozilla peut aller directement dans le répertoire sans regarder dans un fichier JAR.
Si vous bougez le fichier messenger.jar autre part et mettez à jour son chemin dans la liste des paquetages chrome déclarés de Mozilla, la messagerie fonctionnera toujours puisqu'elle ne dépend pas de son emplacement d'installation. En utilisant les URLs chrome, nous pouvons laisser ce genre de détails à Mozilla. De même, si l'utilisateur change son thème, la partie 'skin' de l'URL chrome se traduit vers un ensemble de fichiers différent, et pourtant les fichiers XUL et les scripts n'ont pas besoin d'être changés.
Mozilla est capable de comprendre quel langage et thème sont actuellement utilisés et applique les répertoires appropriés sur les URLS chrome. Le fichier chrome.rdf dans le répertoire chrome et les fichiers contents.rdf sont là pour dire à Mozilla comment faire cela. De cette façon, l'utilisateur peut utiliser n'importe quel thème ou langage mais les URLs qui référencent les fichiers chrome n'ont pas à être changés. Par exemple, le navigator.css par défaut peut être référencé par :
chrome://navigator/skin/navigator.css
Si vous changez le thème du navigateur, l'URL chrome ne change pas, même si l'emplacement réel des fichiers utilisés par le thème change.
Le système chrome prend les sections du navigateur du contenu, du thème courant et du langage courant, et les groupe ensemble pour former une interface utilisateur. Voici d'autres exemples, cette fois pour messenger. Notez qu'aucun des URLs ne spécifie un thème, une langue ni un repertoire spécifique.
chrome://messenger/content/messenger.xul
chrome://messenger/content/mime.js
chrome://messenger/skin/icons/images/folder-inbox.jpg
chrome://messenger/locale/messenger.dtd
Pour des sous-paquetages, la même structure peut être employée. Les URLs suivants se rapporteront à la fenêtre des marque-pages, chacune pour la suite Mozilla et Firefox car le nom du paquetage est différent :
chrome://communicator/content/bookmarks/bookmarksManager.xul (Mozilla)
chrome://browser/content/bookmarks/bookmarksManager.xul (Firefox)
Vous pouvez entrer les URLs chromes n'importe où les URLs normaux peuvent être utilisés. Vous pouvez même les entrer directement dans la barre d'adresse d'une fenêtre du navigateur Mozilla. Si vous entrez un des URLs mentionnés au dessus dans la barre d'adresse du navigateur, vous devriez voir cette fenêtre apparaître comme une page web le ferait et pour la plupart des choses elle fonctionnera comme si elle était une fenêtre séparée. Cependant quelques boîtes de dialogue pourraient ne pas bien fonctionner, si elles attendent des arguments fournis par la fenêtre qui les a ouvertes.
Vous pourriez voir également des URLs chrome sans noms de fichiers spécifiés, tel que :
chrome://navigator/content/
Dans le cas présent, seul le nom du paquetage et la partie sont spécifiés. Ce type de référence sélectionnera automatiquement un fichier approprié depuis le bon répertoire. Pour le contenu, un fichier avec le nom du paquet et une extension XUL est choisi. Dans l'exemple ci-dessus, le fichier navigator.xul est choisi. Pour messenger, messenger.xul serait sélectionné. Lorsque vous créez vos propres applications, vous pourriez créer un fichier pour votre fenêtre principale avec le même nom que le paquetage. Ainsi il pourrait être appelé en utilisant une forme plus courte. C'est commode car ainsi tout ce qu'à besoin de savoir un utilisateur pour pouvoir ouvrir l'application, est le nom du paquetage. Bien sûr, pour les extensions qui modifient l'interface du navigateur, l'utilisateur n'aura pas besoin de connaître l'URL comme l'extension sera présente elle-même dans l'interface utilisateur.
Pour un thème,le fichier paquetage.css est choisi; pour une localisation, le fichier paquetage.dtd est choisi.
Souvenez-vous, l'URL chrome n'est pas relatif à un emplacement sur le disque. Les deux premières pièces sont le nom du paquetage et la partie (content, skin, ou locale). Bien qu'il soit commun de mettre les fichiers de contenu dans un répertoire appelé content, c'est purement une convention, et ces fichiers peuvent être placés dans une structure totalement différente. La seule règle est que la partie nom du fichier de l'URL chrome se refère aux fichiers situés dans le même répertoire où le fichier associé contents.rdf est stocké.
Dans la section suivante, nous verrons comment créer des fichiers contents.rdf et des paquetages.