Architecture

Architecture « classique »

La première idée simple qui vient quand on veut utiliser XUL dans une application web, c'est de simplement remplacer le HTML par XUL. On a donc l'architecture classique (en PHP par exemple) : # un url est demandé ; # une page PHP est exécutée ; # elle génère un écran XUL avec toutes les zones préremplies ; # le résultat est renvoyé vers le navigateur ; # le navigateur affiche l'écran XUL.

Ce type d'architecture a le mérite d'être connue et bien maitrisée par la majorité des développeurs web. Il est donc assez facile, dans un premier temps, de migrer du HTML vers XUL. Il sera toutefois nécessaire, pour les formulaires, de continuer à utiliser du HTML, car XUL n'offre pas le mécanisme de formulaire HTML. Mais c'est toutefois assez simple puisque l'on peut tout à fait mettre des balises HTML dans un fichier XUL.

Malgré tout, cette approche traditionnelle n'est pas satisfaisante, dans la mesure où on n'exploite qu'une toute petite partie des possibilités de XUL et technologies associées.

On a aussi toujours besoin de recharger toute une page, même si c'est pour mettre à jour une valeur d'un champ de saisie par exemple. Cela est donc consommateur de bande passante et c'est assez « lourd ».

L'idéal est donc de se tourner vers une architecture orientée client-serveur/WebServices pour réaliser des applications Web en XUL.

Architecture client-serveur « légère »

Mozilla offre des objets Javascript permettant d'interroger un serveur Web, que ce soit pour récupérer dynamiquement un contenu quelconque à une URL précise ou pour appeler un service web en SOAP ou HTTP classique.

Il sera ainsi possible de ne pas avoir à recharger une page entière pour modifier seulement un élément dans l'écran. Il suffira d'appeler un service Web pour envoyer/récupérer des données et mettre à jour l'écran (en utilisant les fonctions DOM Javascript).

Ainsi pour « poster » un formulaire, on récupère les données contenues dans les champs de saisie (avec les fonctions DOM), et on envoi ces données par un objet XMLHttpRequest vers un URL précis, un script PHP par exemple. Ce script recevra les données sous forme classique (en POST ou en GET), les traitera, et renverra les résultats sous la forme que vous voulez (xml, texte brut, etc.). À vous ensuite d'analyser ces résultats coté XUL : indiquer une erreur dans le formulaire ou passer à un autre écran XUL, etc.

C'est un principe assez ancien, et remis au gout du jour récemment sous le nom marketing Ajax.

De la même manière vous pouvez utiliser des WebServices SOAP, XML-RPC, etc.

Il y a également une autre possibilité pour certains cas. Comme vous le savez, vous pouvez peupler des éléments XUL (tree, liste, etc.) avec des données issues de fichiers RDF. Vous pouvez ainsi tout à fait imaginer que ce fichier RDF soit généré à la volée par un script PHP coté serveur.

L'architecture se résume alors ainsi : #Chargement d'un écran XUL ; # appel d'une URL correspondant à un fichier XUL ; # fichier XUL chargé dans le navigateur ; # Traitement des actions de l'utilisateur dans le fichier XUL ; # dans l'écran XUL : appel de services web -> URL vers serveur ; # script (PHP ou autre) exécuté sur le serveur ; # génère une réponse à l'appel du service (SOAP, XML, texte brut, RDF, etc.) ; # réception de la réponse dans l'écran XUL et traitement de la réponse.

Même si ça a l'air plus compliqué au premier abord, cela apporte des avantages :

1. toute la logique de traitement de l'écran se passe coté navigateur : moins d'échanges avec le serveur (économie de bande passante) et plus de convivialité (réactivité aux actions de l'utilisateur accrue) ;
2. indépendance de l'interface utilisateur avec le fonctionnement « métier » de l'application.

Le développement de l'interface sera certainement plus long que pour une application web traditionnelle, mais le développement coté serveur en sera simplifié puisqu'il ne s'agira que de développer des services web ; services qui par ailleurs pourront être appelés par d'autres applications si besoin est.

Voir le chapitre sur les WebServices pour mieux comprendre leur utilisation.

Architecture client-serveur « lourde »

Dans les deux types d'architecture précédente, le fichier XUL est chargé à partir d'un serveur web. On est donc limité au niveau des fonctionnalités pour des raisons de sécurité. On ne peut ainsi pas faire appel à des objets XPCOM de Mozilla/Firefox, et donc faire du drag & drop inter-applications, lire des fichiers locaux, etc.

Si ce genre de fonctionnalité est indispensable, il va alors falloir acquérir des privilèges coté navigateur, et donc changer un tant soit peu l'architecture.

Il va falloir mettre tous les fichiers XUL dans un fichier XPI ou JAR. Ensuite, deux solutions : # vous signez le fichier JAR, vous l'installez sur votre serveur web. Pour pouvoir accéder au contenu de ce fichier sans l'installer sur le poste client, il faut installer tout de même la clé publique de la signature en local sur le poste, et appeler les fichiers contenus à l'intérieur de l'archive via une URL du style jar://. En théorie, ça fonctionne, mais il semble qu'il y ait quelque problèmes à l'utilisation (manque de documentation, bug ?) ; # Vous empaquetez vos fichiers XUL dans une extension (donc fichier .xpi) que l'utilisateur doit installer en local, ou encore vous réalisez une application XulRunner. Cette solution est moins lourde que la précédente dans la mesure où dans le cas de Firefox ou XulRunner, on peut profiter du système automatique de mise à jour pour faire évoluer l'application.

Dans les deux cas, vos fichiers XUL contenus dans l'archive (JAR ou XPI) appellerons des services web du serveur comme dans l'architecture client-serveur légère.