Frédéric wrote:
> Bonsoir,
>
> Hier Stéphane m'a parlé un peu de XUL, que je ne connaissais que de nom.
> Je suis ensuite allé farfouiller un peu sur le site de mozilla, et j'ai
> finalement trouvé un site français qui cause de tout cela :
>
> http://xul-fr.org
>
> Il y a pas mal de doc, et en particulier la traduction du tutorial (très
> complet) que l'on trouve sur Xulplanet.
>
> Ceci-dit, j'ai encore un peu du mal à bien comprendre comment s'articule
> tout bins, et je voudrais avoir quelques confirmations.
>
> D'après ce que j'ai lu, Xul est donc un 'langage' de description
> d'interface graphique, basé sur du XML. Cette description est lue par le
> moteur Gecko, implémenté dans Mozilla, Firefox et autres, et le transforme
> en une interface graphique (c'est de cette façon que Mozilla et ses
> copains fonctionnent eux-mêmes).
>
XUL n'est pas basé sur XML, c'est un dialecte de XML (comprendre : c'est
du XML, avec la définition spécifique de balises). Les balises sont
spécifiques à la description d'interface utilisateur. C'est une
technologie à rapprocher par exemple de glade pour gtk.
Il faut encore généralement associer un fichier XUL à une bibliothèque
de méthodes d'évènement pour gérer l'aspect dynamique de l'interface. Le
plus simple pour cela reste javascript.
> Ensuite, on a XPCOM. Là, j'y vois moins clair. Est-ce bien le code
> (nativement en javascript, mais des binding Perl, Python et autres
> commencent à voir le jour) qui est exécuté derrière les actions
> utilisateurs ?
Non, XPCOM est une architecture de composants. C'est un moyen de
spécifier un "objet" (que les puristes me pardonnent) avec la
déclaration de ses interfaces, des ressources dont il a besoin, etc.
Une sorte de package pour la distribution simplifiée de fonctionnalités.
XPCOM peut quasiment être codé en n'importe quel langage, car il y a un
interfaçage. Néanmoins, on utilise généralement javascript qui a un
interpréteur natif, et si on a besoin de rapidité C++. Dans les deux
cas, il n'y pas besoin de couche d'interface.
>
> Pour aller plus loin, il me semble avoir lu que le code XUL/XPCOM peut être
> soit installé en local, soit être interprété dynamiquement par le
> navigateur en se connectant sur un serveur qui lui envoit un fichier XUL.
> Est-ce exact ? Mais dans ce cas, où est le code XPCOM ? Comment l'appli
> saura-t-elle réagir à tel ou tel évènement utilisateur ?
Vrai, on peut paramétrer apache pour qu'il servent ces fichiers avec le
bon mime-type, et baisser le niveau de sécurité de mozilla pour qu'il
accepte de faire tourner du code fourni par un serveur. Bien entendu, il
est fortement déconseillé d'aller sur le web avec un moz dans cette
configuration.
>
> Est-ce que j'oublie des choses importantes dans ces mécanismes ?
>
Oui, si on se contente de vouloir étendre un logiciel éxistant (moz,
firefox ou autre), on a mieux fait de développer une extension qui
permet de s'immiscer dans le logiciel, ou si la fonctionnalité vraiment
trop éloignée des services fournis par l'appli hébergeant, on a encore
la possibilité d'ajouter un greffon.
> J'aimerais avoir l'avis et les commentaires d'une personne qui a déjà
> baignée dans tout ça, car j'aurais des questions complémentaire sur des
> applications potentielles qui m'intéressent dans le cadre de mon boulot.
> De mon côté, je poursuis mes lectures...
>
> Merci d'avance.
>
--
* Jean-Noel Avila Tel. : +33 (0)4 79 25 31 32
* ALEPH S.A. Fax : +33 (0)4 79 25 24 27
* Savoie Technolac BP 264
* F-73375 Le Bourget du Lac
