Xtf

XTF: Un framework d'extension de balises (eXtensible Tab Framework)

XTF vous permet d'implémenter dans Mozilla de nouveaux éléments XML dans des modules XPCOM. Il ne s'agit pas d'une version C++ de XBL : les éléments XTF peuvent être écrits dans n'importe quel langage compatible XPCOM. Alex Fritze s'astreint même à écrire la plupart des éléments en JavaScript.

Le support de XTF doit impérativement être activé lors de la compilation de Mozilla en spécifiant l'option '--enable-xtf'' (par l'ajout de "ac_add_options --enable-xtf" dans votre fichier .mozconfig) (ndt: activé par défaut).

Pour servir un espace de nommage particulier "urn:mycompany:mynamespace" dans vos propres éléments XTF, créez un composant XPCOM qui implémente l'interface nsIXTFElementFactory, et faites son enregistrement avec le gestionnaire de composant sous le contract id "@mozilla.org/xtf/element-factory;1?namespace=urn:mycompany:mynamespace". À chaque fois que Mozilla rencontrera une balise dans votre espace de nommage, il appellera la fonction 'createElement()' de votre classe d'objet. Cette fonction doit soit retourner un nouvel élément XTF (un objet implémentant 'nsIXTFElement' et quelques autres interfaces selon le type de fonctionnalités requises), ou soit 'null'. Dans ce dernier cas, l'implémentation construira un élément XML générique.

Toutes les interfaces en rapport avec des modules de classe XTF ou des éléments XTF sont disponibles dans mozilla/content/xtf/public/. Le code d'implémentation lui même est réparti entre les répertoires mozilla/content/xtf/ et mozilla/layout/xtf/.

Liaison d'éléments d'extrémité (éléments document)

La liaison d'éléments d'extrémité n'est pas (encore) supportée. Selon l'utilisation de vos éléments XTF, ceci peut être ou ne pas être un problème. Si vous utilisez XTF pour implémenter tout un nouveau langage plutôt que de simples outils graphiques à mettre dans des documents html, xul ou svg, alors vous allez probablement empaqueter vos documents dans un élément XML avec un style (par ex via une feuille de style) permettant de bien les afficher plutôt que de bien les imprimer. Cet élément d'extrémité peut se situer dans votre espace de nommage XTF aussi longtemps que votre classe XTF renvoie une erreur pour cette balise élément. L'implémentation va alors créer un élément XML générique pour cet élément.

XTF et XUL

Lors de l'utilisation d'éléments XTF dans des documents XUL, notez que le document propriétaire (aussi bien wrapper.ownerDocument que wrapper.elementNode.ownerDocument) aura une valeur null au moment de l'appel de onCreated() (pour des documents XML et SVG, seul wrapper.ownerDocument devrait être non-null). Ceci est dommage car il est souvent avantageux de construire l'arborescence de contenu visuel au moment de l'appel de onCreated() et ne pas attendre que le contenu visuel soit explicitement sollicité. Ainsi, les attributs placés sur les éléments XTF pourraient être directement appliqués aux éléments de l'arborescence de contenu visuel. Il est possible de construire l'arborescence de contenu en utilisant un document différent du document cible, mais cela nécessite en contrepartie d'appliquer de subtiles liaisons XBL - voir ci-dessous.

XTF et XBL

Les éléments XTF se comportent généralement très bien en conjonction avec XBL. Il y a quelques problèmes avec les éléments liés en XBL dans un visualContent de XTFVisual à cause du fait que les liaisons XBL sont attachées aux éléments au moment de la mise en page plutôt que lors de la phase de construction de l'arborescence de contenu : l'accès aux interfaces des éléments liés par XBL ou des objets JS avant la phase de mise en page n'entraine généralement pas le résultat escompté. Par exemple, une liste déroulante listbox n'aura pas les membres 'appendItem', 'clearSelection', etc. avant la phase de mise en page, même si avec un queryInterface pour nsIDOMXULMenuListElement. Pire, si le contenu visuel a été construit dans un document différent (à cause de l'indisponibilité du document cible lors de la phase de construction de l'arborescence de contenu - voir ci-dessus), alors l'objet JS obtenu avant la phase de mise en page peut être différent de celui qui recevra au final l'implémentation de la liaison, c'est-à-dire que même un queryInterface ultérieur échouera. Pour contourner ces problèmes, le contenu lié à XBL devrait a) soit être construit le plus tard possible (i.e. lorsque le conteneur le sollicite par l'appel de nsIXTFVisual::GetVisualContent()) ou b) si ceci n'est pas possible (par exemple parce que vous voulez placer des attributs directement dans l'arborescence de contenu visuel), toutes les références aux objets JS de l'élément devraient être ré-évaluées au moment de la première mise en page (par l'écoute des notifications DidLayout()).

Bugs

1. Pour des éléments XTF écrits en JS (et aussi en C++), la construction d'un visuel visualContent utilisant le même document que le visuel entraine d'affreux cycles de référencement qui empêchent les conteneurs, les éléments XTF intérieurs, le contenu anonyme et également l'ensemble du document de pouvoir être détruits. Une solution consisterait à construire le visualContent dans un document différent (par exemple définir le document dans nsXMLContentBuilder à null, ou ne pas le définir du tout, permettra à un contenu nouveau d'être construit dans un nouveau document temporaire).

2. Les éléments liés par XBL se comportent étrangement si du JS tente d'accéder à n'importe quel contenu XUL placé après eux trop tôt. Exemple :

  <groupbox>
    <caption><[[xtf:foo/></caption]]>
    <label value="label text"/>
   </groupbox>

Si le JS implémenté par l'élément XTF 'foo' accède à du contenu XUL avant d'avoir reçu la notification 'didLayout', la boîte de groupe groupbox ne sera pas construite correctement (elle ne contiendra pas le libellé texte). L'accès à du contenu XUL inclut toutes les opérations qui conduisent à la construction d'un conteneur JS pour un élément XUL. Par exemple, si l'élément XTF écoute les notifications de parentChanged, un conteneur sera construit pour le paramètre de notification 'parent' et la construction de boîte de groupe groupbox échouera mystérieusement.

3. Quelques interfaces XUL ne peuvent pas être utilisées via XPCOM et donc ne pas fonctionner comme prévu. Par exemple, la méthode nsIDOMXULSelectControlElement::insertItemAt() d'un menulist est censée retourner un élément de type nsIDOMXULSelectControlItemElement. Toutefois, puisque l'implémentation XBL de insertItemAt du menulist crée un élément XUL qui ne sera lié qu'au prochain événement asynchrone de mise en page, le queryInterface de nsIDOMXULSelectControlItemElement échouera. Le résultat est que la méthode appelée échouera toujours lorsqu'elle est invoquée depuis XPCOM. Une solution pragmatique consisterait à modifier les signatures d'interface pour retourner nsIDOMXULElement plutôt que nsIDOMXULSelectControlItemElement.

4. L'appel à un queryInterface du conteneur d'un élément XTF implémenté en JS depuis JS comme dans

 element.QueryInterface(Components.interface.nsIXTFPrivate);

entraine occasionnellement l'assertion

 ###!!! ASSERTION: tearoff not empty in dtor:
   '!(GetInterface()||GetNative()||GetJSObject())',
   file /home/alex/devel/mozilla/js/src/xpconnect/src/xpcinlines.h, line 627

avec comme résultat que le QI a réussi (i.e. sans envoyer une exception) mais les méthodes et propriétés de l'interface ne sont pas disponibles après le queryInterface, même si l'élément implémente la bonne interface.

Ceci semble se produire lorsque GC est est détruit *après* que l'invocation de l'interface de l'élément XTF (qui résulte de la création d'un nsXTFInterfaceAggregator) mais *avant* que nsXTFInterfaceAggregator n'ait été empaqueté pour une utilisation dans JS par XPCConvert::NativeData2JS().

La solution consiste à a) soit exposer l'interface via getScriptingInterfaces (auquel cas elle sera disponible pour des appels JS automatiquement), ou b) n'appeler queryInterface qu'après que l'interface a été correctement installée, par exemple :

 while (!element.inner)
   element.QueryInterface(Components.interface.nsIXTFPrivate);

Avec ce code, le queryInterface réussira dans la première ou seconde itération.

(7 octobre 2004 Alex Fritze <alex@croczilla.com>)

interfaces XTF client

• nsIXTFElementFactory
• nsIXTFElement
  • nsIXTFGenericElement
  • nsIXTFVisual
    • nsIXTFXMLVisual
    • nsIXTFXULVisual
    • nsIXTFSVGVisual
    • nsIXTFAttributeHandler

interfaces du framework

• nsIXTFElementWrapper
  • nsIXTFGenericElementWrapper
  • nsIXTFXMLVisualWrapper
  • nsIXTFXULVisualWrapper
  • nsIXTFSVGVisualWrapper