Discussion :

[PouetteMan]

**Je n'ai fait attention qu'après qu'il y avait le forum XSLT, si un modérateur juge que ce sujet à plutôt sa place là-bas, il peut le déplacer. Désolé**

Bonjour à tous !

Je viens vers vous après un problème qui m'a occupé pratiquement tout mon weekend... Je veux faire l'index d'une FAQ.

Voici mon fichier xml :

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
20
21
22
23
24
25
26
27
28
 
<faq>
	<entry>
		<rubrique>RubriqueA</rubrique>
		<titre>Problème1</titre>
		<contenu>Ceci est le contenu</contenu>
	</entry>
	<entry>
		<rubrique>RubriqueA</rubrique>
		<titre>Problème2</titre>
		<contenu>Ceci est le contenu</contenu>
	</entry>
	<entry>
		<rubrique sous_rubrique="Partie1" >RubriqueA</rubrique>
		<titre>Problème3</titre>
		<contenu>Ceci est le contenu</contenu>
	</entry>
	<entry>
		<rubrique>RubriqueB</rubrique>
		<titre>Problème4</titre>
		<contenu>Ceci est le contenu</contenu>
	</entry>
	<entry>
		<rubrique sous_rubrique="Partie1" >RubriqueB</rubrique>
		<titre>Problème5</titre>
		<contenu>Ceci est le contenu</contenu>
	</entry>
</faq>

J'aimerais obtenir ceci (note: les "entry" sans sous-rubriques vont dans DIVERS):

RubriqueA

Divers

Problème1
Problème2

Partie1

Problème3

RubriqueB

Divers

Problème4

Partie1

Problème5

J'y arrive pas trop mal, sauf que mon XSLT à un problème dans un cas particulier...
Quand j'ai deux "Entry" de "Rubrique" différentes, mais qui possèdent le même nom de "sous_rubrique" (comme c'est illustré dans l'exemple) j'obtiens ca :

RubriqueA

Divers

Problème1
Problème2

Partie1

Problème3

RubriqueB

Divers

Problème4

Les éléments les sous-rubriques du même nom (ici "Partie1" associée au problème5 et au problème3) ne sont calculés qu'une fois. Une fois qu'elle a été trouvée dans la première rubrique, la sous rubrique ne s'affichera pas dans la rubrique suivante...


J'utilise des Muenchians pour dédoublonner les rubriques.
Voici mon xslt :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
...
<xsl:key name="RUBRIQUE" match="entry" use="rubrique"/>
<xsl:key name="SOUSRUBRIQUE" match="entry" use="rubrique/@sous_rubrique"/>
 
			<!--Table des matières-->
			<div id="TOC">
			<div class="titreTOC">INDEX</div>
				<ul>
					<xsl:for-each select="//entry[generate-id() = generate-id(key('RUBRIQUE', ./rubrique)[1])]">
					<xsl:sort select="rubrique"/>
						<li><xsl:value-of select="./rubrique/text()"/></li>
						<ul>
							<li><ul>
								<xsl:for-each select="//entry[rubrique=current()/rubrique/text()]">
									<xsl:if test="not(current()/rubrique/@sous_rubrique)">
										<xsl:apply-templates select="titre" mode="TOC"/>
									</xsl:if>
								</xsl:for-each>
							</ul></li>
							<xsl:for-each select="//entry[rubrique=current()/rubrique]">
							<xsl:sort select="rubrique/@sous_rubrique"/>
									<xsl:for-each select="current()[generate-id() = generate-id(key('SOUSRUBRIQUE', ./rubrique/@sous_rubrique)[1])]">
										<li><xsl:value-of select="./rubrique/@sous_rubrique"/></li>
										<ul>
											<xsl:for-each select="//entry[rubrique=current()/rubrique/text() and rubrique/@sous_rubrique=current()/rubrique/@sous_rubrique]">
											<xsl:sort select="titre"/>
												<xsl:apply-templates select="titre" mode="TOC"/>
											</xsl:for-each>
										</ul>
									</xsl:for-each>
							</xsl:for-each>
						</ul>
					</xsl:for-each>
				</ul>
			</div>
			<!--FIN de la table des matières-->
...

Je suis sous XMLSpy, j'ai tenté le debug mode et je ne comprends pas pourquoi il ne va pas chercher mes sous-rubrique au second passage... pourtant ils sont présents dans la liste de noeuds quand il doit les traiter.

Je débute encore et toujours. Ne vous étonnez pas si vous pensez que ma méthode pour générer cet index est "Dinosaure"
Sur cette FAQ, je n'ai pas de contrainte (c'est moi qui crée tout) donc je suis ouvert à d'autre propositions d'architecture ou d'algorithme.

Par contre, je suis sous XSLT 1.0

Merci d'avance !

[thelvin]

Je suis sous XMLSpy, j'ai tenté le debug mode et je ne comprends pas pourquoi il ne va pas chercher mes sous-rubrique au second passage... pourtant ils sont présents dans la liste de noeuds quand il doit les traiter.

? Euh... Le pourquoi me semble portant assez évident.
De même que tu utilises un Muench pour dédoublonner les rubriques, tu utilises un Muench pour dédoublonner les sous-rubriques. Où est la différence ? Moi j'en vois pas. Quel est l'effet d'un dédoublonnage ? N'avoir qu'une seule fois chaque valeur.
Donc si tu as plus d'une fois une sous-rubrique de même nom, elle n'apparaît qu'une fois. Logique.
Je me doute bien que c'est pas ce que tu veux, mais... C'est ce que tu as demandé. Tu as demandé la même chose que pour les rubriques. Donc tu obtiens la même chose que pour les rubriques. Voilà pourquoi.

Alors comment régler ça ?
Ce que tu veux dédoublonner, c'est pas les sous-rubriques. Ce sont les couples (rubrique, sous-rubrique).

Voici une manière d'écrire la clé, je te laisse adapter le reste :

Code :

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

<xsl:key name="SOUSRUBRIQUE" match="entry" use="concat(rubrique, '/', rubrique/@sous_rubrique"/>

Je débute encore et toujours. Ne vous étonnez pas si vous pensez que ma méthode pour générer cet index est "Dinosaure"

En XSLT 1.0 il n'y a pas de manière pratique de dédoublonner ou regrouper. Celle-ci est probablement la meilleure.

Par contre, concernant ton XML lui-même, ça aurait pu être malin de lui donner directement la bonne structure au lieu de devoir regrouper plus tard dans une stylesheet.
Là, il n'est pas beaucoup plus intéressant qu'un CSV. Du coup, l'intérêt de faire du XML et du XSLT, il est pas évident évident.

[PouetteMan]

Merci pour ta réponse thelvin.

Mon raisonnement était un peu fait dans le brouillard... car il est vrai qu'en lui demandant de dédoublonner, je ne pouvais avoir que ca comme résultat !

J'avoue ne pas encore avoir le recule pour être sûr de saisir complètement la syntaxe d'un Muenchian. J'imaginais que me solution pouvait marcher (en pensant que cela dépendait du noeud à traiter).


Quoiqu'il en soit, cela fonctionne parfaitement avec ton tuyau !

Par contre, concernant ton XML lui-même, ça aurait pu être malin de lui donner directement la bonne structure au lieu de devoir regrouper plus tard dans une stylesheet.
Là, il n'est pas beaucoup plus intéressant qu'un CSV. Du coup, l'intérêt de faire du XML et du XSLT, il est pas évident évident.

Ce système de FAQ est destiné à être rempli par certains utilisateurs au travers d'une interface formulaire + script php qui permettra de rajouter une entrée ou de modifier une existante. Je veux seulement m'affranchir de la base de données.

Je vais essayer de creuser vers une solution de stockage CSV (que je n'ai pas l'habitude de manipuler) pour voir si je peux avoir la même chose sans contraintes.


A bientôt.

[Loceka]

Je vais essayer de creuser vers une solution de stockage CSV (que je n'ai pas l'habitude de manipuler) pour voir si je peux avoir la même chose sans contraintes.

Ce que te disais thelvin c'était que la structure actuelle de ton XML n'était pas beaucoup plus simple à traiter qu'un format CSV. Il faut donc comprendre qu'un format CSV n'est pas idéal pour traiter les données (il n'y a aucune notion de sémantique etc.).

Ce qu'il te conseillait implicitement au contraire, c'était de modifier la structure de ton XML pour qu'il soit plus facile à traiter par la suite.

Par exemple tu pourrais le construire comme ceci :

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
<faq>
	<rubrique name="RubriqueA">
		<sous_rubrique name="Divers">
			<entry title="Problème1">Ceci est le contenu</entry>
			<entry title="Problème2">Ceci est le contenu</entry>
		</sous_rubrique>
		<sous_rubrique name="Partie1">
			<entry title="Problème3">Ceci est le contenu</entry>
		</sous_rubrique>
	</rubrique>
	<rubrique name="RubriqueB">
		<sous_rubrique name="Divers">
			<entry title="Problème4">Ceci est le contenu</entry>
		</sous_rubrique>
		<sous_rubrique name="Partie1">
			<entry title="Problème5">Ceci est le contenu</entry>
		</sous_rubrique>
	</rubrique>
</faq>

Il est tout aussi facile de générer un tel XML à partir des données utilisateurs et il est déjà formé de façon "logique" donc beaucoup plus simple à traiter.

[PouetteMan]

Merci, j'en prends bonne note.

J'étais parti sur cette structure dans une logique (et c'est là que le parallèle avec le CSV prends son sens du coup...) de pouvoir ajouter une entrée à la suite de mon ficher XML. Simplement en écrivant à la suite.
Et ce, sans devoir charger la totalité de mon arbre puis enregistrer la totalité de mon fichier en écrasant le précédant. (Dans l'hypothèse où le fichier deviendrait gros!)

Mais je ne ne rends pas tellement compte de la puissance de calcul de PHP sur du XML (j'utilise SimpleXML pour les modifications et un simple fopen fwrite pour l'ajout d'une entrée).
Peut-être qu'il est tout à fait capable de gérer d'énormes fichiers sans ralentissements ?


Peut-être qu'avec ma méthode, pensant économiser des ressources à l'écriture, j'en perds à l'affichage de mon fichier ?


Merci de vos lumières.

[Loceka]

Je doute fort qu'une FAQ puisse entrainer la création de "gros" fichiers. Je dirais que jusqu'à 10 Mo (chiffre assez empirique, j'avoue) il ne devrait pas y avoir de problème de traitement (chargement en RAM, taille de la stack, ...). Or une FAQ ne devrait pas atteindre cette taille là avant un bon bout de temps.

D'ailleurs tu aurais le même souci avec ton format fichier XML étant donné que le XSL requiert l'utilisation de DOM (donc chargement complet du XML en mémoire) et l'utilisation de clé dans tous les sens avec des for-each imbriqués ne ferait que ralentir plus le traitement.

Là tu remarques que le format que j'ai proposé prend beaucoup moins de place que celui que tu avais choisi (1 ligne par entrée au lieu de 5) ce qui fait que le fichier grossira beaucoup moins vite. De plus le traitement en XSL sera fait de façon linéaire, sans clé, sans cross-reference ni rien.

Donc oui, l'écriture dans le fichier sera peut-être plus coûteuse vu que tu ne pourras pas utiliser de SAX (et encore), mais son interprétation sera beaucoup plus fluide.

[PouetteMan]

Merci pour ces riches conseils.
Je vais les appliquer.