9.5 Règles avançées

Attention : Ce tutoriel est ancien et n'est pas mis à jour. Bien que beaucoup d'informations soient encore valables pour les dernières versions de gecko, beaucoup sont aussi obsolètes. Il est préférable d'aller consulter cette page sur la version française de ce tutoriel sur developer.mozilla.org.

Cette section décrit la syntaxe des règles les plus complexes.

La syntaxe des règles complètes

La syntaxe des règles décrites jusqu'ici est utile pour certaines sources de données, mais parfois les données doivent être affichées de manière plus sophistiquée. La syntaxe de règle simple n'est en fait qu'un raccourci pour la syntaxe de règle complète qui est décrite ci-dessous. Comme pour la syntaxe de règle simple, la règle complète est placée entre des balises rule.

Une syntaxe de règle complète contient trois balises filles : une balise conditions , une balise bindings et une balise action. La balise bindings n'est pas toujours nécessaire.

L'élément conditions spécifie le critère qui doit correspondre à une ressource donnée. Vous pouvez spécifier plusieurs conditions qui doivent toutes correspondre à la ressource donnée. En utilisant la syntaxe de règle simple, les conditions sont directement placées dans l'élément rule.

Si les conditions correspondent à une ressource donnée, le contenu placé entre les balises action est généré. Dans la syntaxe de règle simple, le contenu est directement placé dans la balise rule.

Conditions d'une règle

Lorsque qu'un arbre, un menu ou tout autre élément avec une source de données génère son contenu, le générateur de modèle cherche en premier lieu la ressource marquée par l'attribut ref. L'opération est ensuite répétée pour l'ensemble des ressources filles. Le générateur compare chaque ressource aux conditions. Si celles-ci sont vérifiées, le contenu de l'élément action est généré pour ces ressources. Si elles ne sont pas vérifiées, rien n'est généré.

Élément content

L'élément conditions contient trois sous-éléments. Le premier est l'élément content qui ne doit être présent qu'une seule fois. Il sert de marqueur lorsque le générateur de modèle parcourt les ressources. Il indique le nom de la variable dans laquelle est placée une référence à la ressource racine pendant que les conditions sont analysées. La ressource racine est indiquée par l'attribut ref dans l'élément contenant le modèle.

La syntaxe d'un élément content est la suivante :

<content uri="?var"/>

La point d'interrogation indique que le texte qui suit est une variable. Vous pouvez alors utiliser la variable var dans le reste des conditions. Bien entendu, vous pouvez nommer la variable comme vous le voulez.

Élément member

L'élément suivant est l'élément member qui est utilisé pour parcourir un ensemble de ressources filles. En termes RDF, il est comparable à Seq, Bag ou Alt. Imaginons que vous ayez une liste de villes, comme dans l'extrait RDF/XML suivant :

<RDF:Seq RDF:about="http://www.xulplanet.com/rdf/weather/cities">
  <RDF:li RDF:resource="http://www.xulplanet.com/rdf/weather/city/paris"/>
  <RDF:li RDF:resource="http://www.xulplanet.com/rdf/weather/city/Manchester"/>
  <RDF:li RDF:resource="http://www.xulplanet.com/rdf/weather/city/Melbourne"/>
  <RDF:li RDF:resource="http://www.xulplanet.com/rdf/weather/city/Kiev"/>
</RDF:Seq>

<RDF:Description RDF:about="http://www.xulplanet.com/rdf/weather/city/paris">
  <cityset:name>paris</cityset:name>
</RDF:Description>

.
.
.

Vous voulez afficher une ligne dans une arborescence pour chaque ville. Pour accomplir cela, utilisez l'élément member comme ceci :

<tree id="citiesTree" datasources="weather.rdf"
      ref="http://www.xulplanet.com/rdf/weather/cities">
  <template>
    <rule>
      <conditions>
        <content uri="?list"/>
        <member container="?list" child="?city"/>
      </conditions>
    <rule>
  <template>
</tree>

Le générateur de modèle commence par récupérer la valeur de l'attribut ref qui dans ce cas est http://www.xulplanet.com/rdf/weather/cities. Cette ressource va être mise dans la variable list comme il est indiqué par la balise content. Vous obtiendrez les ressources associées à la ressource racine en utilisant la variable list.

Le générateur de modèle s'intéresse ensuite à l'élément member. Le générateur est contraint de parcourir les fils d'un élément. Le parent est indiqué par l'attribut container et les fils par l'attribut child. Dans l'exemple ci-dessus, la valeur de l'attribut container est la variable list. Ainsi le parent sera la valeur de la variable list qui a la valeur de la ressource racine http://www.xulplanet.com/rdf/weather/cities. L'effet induit va être de parcourir la liste de tous les fils de 'http://www.xulplanet.com/rdf/weather/cities'.

Si vous regardez en détail le RDF ci-dessus, la ressource 'http://www.xulplanet.com/rdf/weather/cities' a quatre filles, une pour chaque ville. Le générateur de modèle parcourt chacune d'elle, comparant la fille avec la valeur de l'attribut child. Dans le cas présent, celui-ci contient la valeur city. Donc le générateur va donner à la variable city la valeur des ressources filles au fur et à mesure.

Comme il n'y a pas d'autres conditions, la condition correspond à chacune des quatre ressources et le générateur va créer du contenu pour chacune d'entre elles. Bien sûr, l'exemple ci-dessus n'a aucun contenu. On l'ajoutera par la suite.

Élément triple

L'élément suivant est l'élément triple. Il est utilisé pour vérifier l'existence d'un triplet (ou assertion) dans la source de données du RDF. Un triplet est comme la propriété d'une ressource. Par exemple, un triplet existe entre un marque-page et son URL associée. Il peut-être exprimé ainsi :

Un marque-page vers mozilla.org  ->  URL  ->  www.mozilla.org

Cela signifie qu'il existe un triplet entre le marque-page Un marque-page vers mozilla.org et www.mozilla.org par la propriété URL. La première partie est appelée le sujet, la seconde, le prédicat, et la dernière, l'objet. Exprimé avec l'élément triple, ce mécanisme est décrit comme ceci :

<triple subject="Un marque-page vers mozilla.org"
           predicate="URL"
           object="www.mozilla.org"/>

Ce code a été simplifié par rapport au code réel. Le prédicat devrait normalement inclure les espaces de nommage, et le sujet devrait être l'identifiant ressource du marque-page, et non pas le titre du marque-page comme ici. En fait, le titre du marque-page devrait être un autre triplet dans la source de données, qui utiliserait le prédicat 'nom'.

Vous pouvez remplacer le sujet et l'objet dans l'élément triple par des références aux variables, auquel cas les valeurs seront substituées aux variables. Si aucune valeur n'est définie pour une variable, le générateur de modèle va attribuer à la variable la valeur de la source de données.

Disons, par exemple, que l'on veuille ajouter une prédiction météo à la source de données des villes. Les conditions suivantes peuvent être utilisées :

<conditions>
  <content uri="?list"/>
  <member container="?list" child="?city"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#prediction"
             object="?pred"/>
</conditions>

Le générateur de modèle va parcourir chaque ville comme précédemment. Lorsqu'il arrivera au triplet, il va s'intéresser aux assertions de la source de données RDF pour une prédiction météo. La prédiction météo est attribuée à la variable pred. Le générateur va répéter cette opération pour chacune des quatre villes. Une comparaison a lieu et le générateur va créer du contenu pour chaque ville qui a une prédiction météo associée. Si la ville n'a pas de ressource de prédiction, la condition ne correspond pas et aucun contenu ne sera créé pour cette ville. Remarquez que vous n'avez pas besoin de mettre 'rdf:' au début du prédicat, car il est sous-entendu.

On peut aussi remplacer l'attribut object par une valeur statique. par exemple :

<conditions>
  <content uri="?city"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#prediction"
             object="Nuageux"/>
</conditions>

Cet exemple est similaire mais nous spécifions que nous voulons une comparaison qui s'effectue sur « Nuageux ». Le résultat obtenu est que la condition ne sera remplie que pour les villes dont la prédiction météo est « Nuageux ».

Nous pouvons ajouter davantage de triplets pour réaliser d'autres comparaisons. Par exemple, dans l'exemple ci-dessus, la température et la vitesse du vent peuvent être testées. Pour cela, il suffit d'ajouter un autre triplet qui vérifiera les ressources supplémentaires. La condition sera remplie si et seulement si l'intégralité des triplets retournent des valeurs.

L'exemple ci-dessous va vérifier un triplet supplémentaire appliqué au nom de la ville. Il lui sera attribué une variable name. La condition va correspondre si la ville possède à la fois un nom et une prédiction météo.

<conditions>
  <content uri="?list"/>
  <member container="?list" child="?city"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#name"
             object="?name"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#prediction"
             object="?pred"/>
</conditions>

Générer du contenu

Le contenu à générer pour une règle est spécifié dans l'élément action. Il peut être le contenu des lignes d'un arbre, des items de menu ou tout ce que vous souhaitez générer. À l'intérieur du contenu, vous pouvez vous référer aux variables qui ont été définies dans les conditions. Ainsi, dans l'exemple météo ci-dessus, vous pouvez utiliser les variables name ou pred pour afficher la ville ou la prédiction météo. Vous pouvez aussi utiliser les variables list ou city, mais elles contiennent des ressources et non du texte, donc elles n'auront pas de sens pour les utilisateurs.

Dans la syntaxe de règle simple, la syntaxe uri="rdf:*" est utilisée pour indiquer où le contenu doit être généré. Dans la syntaxe de règles complètes, vous appliquez la valeur de l'attribut uri à une variable que l'on a utilisée dans la partie des conditions. Normalement, ce sera la variable assignée à l'attribut child de l'élément member.

Exemple complet d'arbre

L'exemple suivant montre un arbre complet avec des conditions et une action. Vous pouvez consulter le fichier RDF séparément (Source RDF).

Exemple 9.5.1  Source Voir

<tree id="weatherTree" flex="1" datasources="weather.rdf"
      ref="http://www.xulplanet.com/rdf/weather/cities">
  <treecols>
    <treecol id="city" label="Ville" primary="true" flex="1"/>
    <treecol id="pred" label="Prédiction Météo" flex="1"/>
  </treecols>

  <template>
    <rule>
      <conditions>
        <content uri="?list"/>
        <member container="?list" child="?city"/>
        <triple subject="?city"
                predicate="http://www.xulplanet.com/rdf/weather#name"
                object="?name"/>
        <triple subject="?city"
                predicate="http://www.xulplanet.com/rdf/weather#prediction"
                object="?pred"/>
      </conditions>
      <action>
        <treechildren>
          <treeitem uri="?city">
            <treerow>
              <treecell label="?name"/>
              <treecell label="?pred"/>
            </treerow>
          </treeitem>
        </treechildren>
      </action>
    </rule>
  </template>
</tree>

Deux colonnes apparaissent dans cet arbre, l'une qui affiche la valeur de 'name' pour chacun ligne, et l'autre qui affiche le résultat de la prédiction météo.

Si vous utilisez le marqueur dont-build-content (ne-pas-générer-de-contenu) sur un arbre, remplacez l'élément content par un élément treeitem

Ajouter des liaisons supplémentaires

Le dernier élément que vous pouvez ajouter à l'intérieur d'une règle est l'élément bindings. À l'intérieur de celui-ci, vous pouvez mettre un ou plusieurs éléments binding. Une liaison dans une règle a la même syntaxe qu'un triplet et remplit quasiment la même fonction. Par exemple, dans l'exemple météo précédent, on peut ajouter la liaison suivante :

<bindings>
  <binding subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#temperature"
             object="?temp"/>
</bindings>

La liaison va prendre la ressource "température" de chaque ville et l'attribuer à la variable temp. C'est tout à fait similaire à ce qu'un triplet accomplit. La différence réside dans le fait que la liaison créée par le binding n'est pas prise en compte dans la vérification des conditions. Ainsi, pour qu'une ville soit affichée, il est impératif qu'elle ait un nom et une prédiction météo, mais peu importe qu'elle ait ou non une température. Si toutefois elle en possède une, la valeur sera attribuée à la variable temp et pourra être utilisée dans une action. Si une ville n'a pas de température, la variable temp sera une chaîne de caractère vide.

---

Par la suite, nous verrons comment sauvegarder les états des éléments XUL.