Discussion :

[vogur]

Bonjour,

J'ai un fichier XSL avec des tas de conditions choose / when qui se suivent.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<xsl:template match="liste">
<xsl:choose>
<xsl:when test="(contains(description,'LGaga'))">
<Artiste>Lady Gaga</Artiste>	
</xsl:when>
<xsl:when test="(contains(description,'BSpears'))">
<Artiste>Britney Spears</Artiste>	
</xsl:when>
<xsl:when test="(contains(description,'FPagny'))">
<Artiste>Florent Pagny</Artiste>	
</xsl:when>
</xsl:choose>
</xsl:template>
etc (super long)

Au final, j'aimerais rematcher tout mon arbre de sortie pour supprimer les noeuds "liste" n'ayant pas de noeud "Artiste", donc qui n'ont pas vérifié la boucle.

Bien sûr, on pourrait créer un XML en sortie de cette première boucle puis parser avec un deuxième fichier XSL en éliminant les noeuds intempestifs mais j'aimerais plutôt mettre un code à la suite du précédent pour n'avoir qu'un fichier XSL à traiter.

Est-ce que c'est possible ? Merci

[thelvin]

Non seulement c'est possible, mais le code que tu nous montres en exemple le fait déjà.

Si aucune condition n'est vérifiée, le template sur <liste> ne génère absolument aucune sortie, la <liste> est donc purement et simplement virée sans rien mettre à la place.

[vogur]

Oui en effet... Le code est en réalité un peu plus complexe. J'ai voulu simplifier le code sur le forum pour ne pas embrouiller les lecteurs et ne me suis pas rendu compte qu'au final, il ne collait plus avec la réalité de mon XSL.

En fait, j'ai un client qui m'envoie tous les matins un XML super pénible avec des CDATA à rallonge :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<rss>
<title>NomDuClient</title>
<MAJ>Jeudi 10 octobre 2013 à 06h00</MAJ>
<link>http://www.urlclient.com/</link>
<liste>
<fiche><name><![CDATA[Lady Gaga]]></name>
			<url>http://www.urlclient.com/ladygaga</url>
			<desc><![CDATA[ Biographie de Lady Gaga... Bla bla bla... Dernier album sorti le 15 septembre 2013... bla bla bla ... le disque coûte 10 euros... bla bla bla... il y a 15 disques neufs en stock... bla bla bla... il y a seulement 3 disques d'occasion disponibles... bla bla bla... ]]></desc>
</fiche>
<fiche><name><![CDATA[Britney Spears]]></name>
			<url>http://www.urlclient.com/britney</url>
			<desc><![CDATA[ Biographie de Britney Spears... Bla bla bla... Dernier album sorti le 2012-08-30T00:00:00... bla bla bla ... le disque coûte 9 euros... bla bla bla... il y a 8 disques en stock dont 5 neufs et 3 d'occasion... bla bla bla... bla bla bla... ]]></desc>
</fiche>

Il y a donc des fiches artistes avec un élément name, une url et une description qui pourrait être transformée en une dizaine de nouveaux noeuds comme <DateSortieDernierAlbum>, <StockNeuf>, <StockOccaz>, <PrixNeuf>, <PrixOccaz>, etc.

Pour cela, j'ai remarqué que le client utilisait (heureusement) souvent les mêmes formules pour annoncer le prix du disque. Un substring-before et after avec "le disque coûte" et "euros" par exemple permet de sortir le prix pour bon nombre de fiches. Mais pour la date de sortie, il y a 3 ou 4 formules différentes : 30 octobre 2013, 2013-10-30, 30/10/2013, etc. Ainsi j'utilise une boucle choose pour sortir certains éléments en fonction de la formule utilisée.

Mon XSL est donc bâti comme suit :
- boucle avec des conditions pour sortir la date de sortie du disque
- boucle avec des conditions pour sortir le prix neuf
- boucle avec des conditions pour sortir le prix occaz
- boucle avec des conditions pour sortir le stock occaz
- boucle avec des conditions pour sortir le stock neuf
- etc.

La plupart des fiches étant rédigées avec des formules stéréotypées, elles auront tous les éléments en sortie. Hélas, il y a des fiches parasites avec des formules exceptionnelles qui ne seront pas reconnues par mes boucles if ou choose ou qui n'ont pas d'état des stocks par exemple dans le CDATA. Elles auront donc un ou plusieurs éléments manquants en sortie.

J'aimerais donc rematcher la liste des fiches en sortie qui n'ont pas tous les éléments afin de les éliminer.

Le plus simple que j'ai trouvé est de sortir un premier XML puis de redonner un coup de XSL pour supprimer les fiches n'ayant pas tous les éléments. Mais si on pouvait mettre à la suite du premier XSL, une boucle avec match="parmi les fiches sorties ci-dessus", ça serait top.

[thelvin]

Hum. Il y a une technique simple mais dont la syntaxe en 1.0 n'est, à mon avis, pas évidente.

D'abord la méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<xsl:variable name="artiste">
  <xsl:choose>
    <xsl:when test="(contains(description,'LGaga'))">
      <Artiste>Lady Gaga</Artiste>	
    </xsl:when>
    <xsl:when test="(contains(description,'BSpears'))">
      <Artiste>Britney Spears</Artiste>	
    </xsl:when>
    <!-- etc, et rien si aucune condition n'est vérifiée -->
  </xsl:choose>
</xsl:variable>
 
<xsl:if test="string($artiste)">
  <balise>
    <des-trucs/>
    <des-machines/>
    <xsl:copy-of select="$artiste"/>
  </balise>
</xsl:if>

Normalement c'est assez parlant, sauf ce test="string($artiste)". Pourquoi pas juste test="$artiste" ?
Parce que ça marcherait pas.

La raison technique c'est que $artiste contient un "result tree fragment", un contenu généré par XSLT. C'est un type de donnée à part, qui ressemble aux node-sets venant du document source, mais avec quelques différences. Notamment un result tree fragment est toujours considéré comme englobé par un unique élément racine autour. Donc même si on met rien dedans, il y a quand même l'élément englobant, et un test d'existence dira donc que l'élément englobant existe.
En passant par string(), on isole seulement le contenu texte du result tree fragment, et on vérifie si ce texte contient plus de zéro caractère. Si on a effectivement eu quelque chose à mettre dedans, en principe il y a aussi du texte et donc la condition est vérifiée. Sinon, il n'y a pas de texte et la condition n'est pas vérifiée.

[vogur]

C'est... fantastique ! Merci !

J'avais abandonné les variables à cause de cette histoire de string. Mais c'est très clair maintenant.