DOMDocument pour création de xml

Version imprimable

Je tente de boucler sur un résultat de requête pour générer une sortie XML

le résultat de requête a cette structure :

produit	nom_pdf	type_pdf	prive_pdf
1	ENTREE_AIR_AUTO_RE_FR_FR_28143161	Rapport d essai	0
1	M_FT_FR_FR_201803	Fiche technique	0
100	AMD+C_FT_FR_FR_201901	Fiche technique	0
1000	APDR_FT_FR_FR_201907	Fiche technique	0
1000	ATTESTATION_A1_CONVENTIONNELS	Procès-verbal	1

la sortie XML doit avoir cette structure :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml version="1.0" encoding="UTF-8"?>
<Products>
<product code="A010251">
<Fichiers>
<Fichier nom_fichier = "" type_fichier = "" prive = ""/>
<Fichier nom_fichier = "" type_fichier = "" prive = ""/>
<Fichier nom_fichier = "" type_fichier = "" prive = ""/>
</Fichiers>
</product>
<product code="A010251">
<Fichiers>
<Fichier nom_fichier = "" type_fichier = "" prive = ""/>
<Fichier nom_fichier = "" type_fichier = "" prive = ""/>
<Fichier nom_fichier = "" type_fichier = "" prive = ""/>
</Fichiers>
</product>
</products>

J'ai donc ce code php :

Code:

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
38
39
40
41
42
43
44
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->preserveWhiteSpace = false;
$xml->formatOutput = true;
$Products = $xml->createElement('Products');
 
 
    while($prod_line = mysqli_fetch_array($res)){
 
            if ( $prod_line['produit'] !== $prevprod ){ //product start
                    $product = $xml -> createElement('product');
                    $product -> setAttribute("code", $prod_line['produit']);
 
                    $Fichiers = $xml -> createElement('Fichiers');
 
                        $fichier = $xml -> createElement('fichier');
 
                        $fichier -> setAttribute("nom_fichier", $prod_line['nom_pdf'] );
                        $fichier -> setAttribute("type_fichier", $prod_line['type_pdf'] );
                        $fichier -> setAttribute("prive", $prod_line['prive_pdf'] );
 
            }
 
            else { //same product
 
                        $fichier = $xml -> createElement('fichier');
 
                        $fichier -> setAttribute("nom_fichier", $prod_line['nom_pdf'] );
                        $fichier -> setAttribute("type_fichier", $prod_line['type_pdf'] );
                        $fichier -> setAttribute("prive", $prod_line['prive_pdf'] );
 
 
                }
 
        $Fichiers -> appendChild($fichier);                
        $product ->  appendChild($Fichiers);
        $Products -> appendChild($product);    
 
 
        $prevprod = $prod_line['produit'];
 
    }
$xml -> appendChild($Products);
$xml->formatOutput = true;
echo $xml->saveXML();

J'ai un triangle des bermudes à la sortie car il me sort cette structure:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
<?xml version="1.0" encoding="UTF-8"?>
<Products>
<product code="A010251">
<Fichiers>
<Fichier nom_fichier = "" type_fichier = "" prive = "">
  <Fichier nom_fichier = "" type_fichier = "" prive = "">
     <Fichier nom_fichier = "" type_fichier = "" prive = "">
     </Fichier>
  </Fichier>
</Fichier>
 
</Fichiers>
</product>

Lorsque le code produit est identique à la ligne précédents il est supposé rajouter une balise <fichier> dans la balise <Fichiers> du produit...
Mais en fait il rajoute une balise <fichier> comme enfant de la précédente balise fichier ?????
Je ne m'explique pas ce comportement ????
Voyez vous la source de cette erreur?

Ce qui me semble d'autant plus étrange c'est que les autres appendChild sont corrects,

Quelle sont les autres possibilités pour créer une structure XML dans une boucle ?

Je peux toujours concaténer les string complet ...

06/09/2021, 16h02
SpaceFrog

J'explore la piste du navigateur qui semblerait ne pas interpréter correctement les balises autofermante ...
Quand j'ai généré le XML en mode concaténation de texte avec

Code:

<fichier> </fichier>

les imbrications sont correctes ...
06/09/2021, 17h15
SpaceFrog

Je confirme, sous Brave, et ce sans doute à cause de l'ajoute de plugins qui viennent rajouter de éléments dans le DOM, bine que la page ait un header xml, la page comporte des balise html head et body, et les balises auto fermantes ne sont pas interprétées correctement.
Le code généré par le php est bien correct

Je clos donc le ticket, après avoir perdu une demi journée la dessus.

Indépendamment de ton problème, ça peut être l'occasion d'utiliser XMLWriter à la place de DOMDocument:

Code:

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
38
39
40
41
42
43
44
45
$csv = <<<'CSV'
produit nom_pdf type_pdf prive_pdf
1 ENTREE_AIR_AUTO_RE_FR_FR_28143161 Rapport_d_essai 0
1 M_FT_FR_FR_201803 Fiche_technique 0
100 AMD+C_FT_FR_FR_201901 Fiche_technique 0
1000 APDR_FT_FR_FR_201907 Fiche_technique 0
1000 ATTESTATION_A1_CONVENTIONNELS Procès-verbal 1
CSV;
 
$lines = explode("\n", $csv);
 
$headers = str_getcsv(array_shift($lines), ' ');
 
$xw = new XMLWriter();
$xw->openMemory();
$xw->startDocument("1.0", "utf-8");
$xw->setIndent(true);
$xw->setIndentString('    ');
$xw->startElement('Products');
 
$prevprod = false;
 
foreach ( $lines as $line ) {
    $data = array_combine($headers, str_getcsv($line, ' '));
 
    if ( $data['produit'] !== $prevprod ) {
        if ( $prevprod ) $xw->endElement();
        $prevprod = $data['produit'];
 
        $xw->startElement('produit');
        $xw->writeAttribute('code', $data['produit']);
    }
 
    $xw->startElement('Fichier');
    $xw->writeAttribute('nom_fichier', $data['nom_pdf']);
    $xw->writeAttribute('type_fichier', $data['type_pdf']);
    $xw->writeAttribute('prive', $data['prive_pdf']);
    $xw->endElement();
}
 
$xw->endElement(); // product (last)
$xw->endElement(); // Products
$xw->endDocument();
 
echo $xw->outputMemory();

demo

07/09/2021, 11h04
SpaceFrog

Merci Cosmo ;)
J'avais regardé XMLWriter, mais opté pour DOMDocument et fini par faire de la concaténation de texte pur m'apercevoir que mon premier code était valide. Je vais également tester XMLWriter pour ma culture personnelle.

Quels en sont les avantages selon toi ?
07/09/2021, 12h15
CosmoKnacki

Selon moi ça devrait être plus rapide car cette extension n'a pas à construire tout un tas d'objets que nécessite DOMDocument, mais c'est pure spéculation, je n'ai pas testé. J'aime bien aussi ses possibilités de gestion du cache d'affichage.
07/09/2021, 16h23
SpaceFrog

Dans ce cas la version à l'ancienne en concaténation de texte devrait être encore plus performante car pas besoin de classe ni de lib ... :D
08/09/2021, 00h47
CosmoKnacki

Ah bah ça c'est sûr, mais en faisant ça, ça revient à travailler sans filet alors que XMLWriter ou DOMDocument t'en procure quand même un pour produire du XML conforme.

À toi de voir si tu es sûr de ton coup. Tu peux même écrire une requête ou une procédure stockée si c'est trop complexe, pour produire directement ton xml avec MySQL.

Je viens de penser à un truc concernant ton problème initial. Est-ce que tu as essayé d'envoyer un header au navigateur avant d'afficher le XML ? : header('Content-Type: application/xml'); (de cette manière, en connaissant la nature de ce qu'il reçoit, il ne tentera pas d'en faire du html à tout prix.)
08/09/2021, 08h47
Séb.

Citation:

Envoyé par SpaceFrog

Je confirme, sous Brave, et ce sans doute à cause de l'ajoute de plugins qui viennent rajouter de éléments dans le DOM, bine que la page ait un header xml, la page comporte des balise html head et body, et les balises auto fermantes ne sont pas interprétées correctement.

Tu peux faire ceci le temps du développement pour éviter les <fichier/> :

Code:

echo $xml->saveXML(null, LIBXML_NOEMPTYTAG);
08/09/2021, 09h09
SpaceFrog

Bien vu Séb.

La question que je me pose du coup c'est " le temps du développement " seulement ?
Il faut que je voie avec l'utilisateur du XML généré si cela lui pose un souci particulier d'avoir des balises fermantes et pas juste des auto fermantes.

Merci à tous !
08/09/2021, 09h39
grunk

Citation:

Envoyé par SpaceFrog

Merci Cosmo ;)
J'avais regardé XMLWriter, mais opté pour DOMDocument et fini par faire de la concaténation de texte pur m'apercevoir que mon premier code était valide. Je vais également tester XMLWriter pour ma culture personnelle.

Quels en sont les avantages selon toi ?

Sur de petits documents , où la performance n'est pas importante , il y'a assez peu d'avantage à utiliser XMLWriter/Reader , DomDocument étant bien plus conviviale.
En revanche dès que les documents grossissent et/ou que les performances sont importantes XMLWriter/Reader est largement au dessus. DomDocument va consommer des centainres de Mo de ram là ou XmlWriter/Reader consommera quelques centaines de kilo ...
XMLWriter c'est "juste" un wrapper de la librairie c libxml d'où ses performances.

Mais la vrai question c'est surtout pourquoi encore faire du XML en 2021 :mouarf:
08/09/2021, 09h50
Séb.

Citation:

Envoyé par SpaceFrog

La question que je me pose du coup c'est " le temps du développement " seulement ?

Je croyais que la visu du XML dans le navigateur c'était juste pour toi pour le développement.
C'est dommage qu'un navigateur ou une extension dégradent ton contenu, tant pis pour l'utilisateur j'ai envie de dire :mouarf:
Tu as vu pour le Content-Type comme proposé par CosmoKnacki ? Cela évitera peut-être aux extensions de trifouiller la data.
08/09/2021, 09h51
Séb.

Citation:

Envoyé par grunk

Mais la vrai question c'est surtout pourquoi encore faire du XML en 2021 :mouarf:

C'est vrai qu'entre JSON et CSV (toujours), ça fait une plombe que je n'ai pas touché du XML.
08/09/2021, 13h06
SpaceFrog

A priori c'est pour un Job Talent :(
09/09/2021, 20h06
CosmoKnacki

Citation:

Envoyé par grunk

Sur de petits documents , où la performance n'est pas importante , il y'a assez peu d'avantage à utiliser XMLWriter/Reader , DomDocument étant bien plus conviviale.

Je ne mets pas XMLReader et XMLWriter dans le même sac.
Pour une tâche de lecture (et surtout pour extraire une information planquée bien profondément dans l'arborescence) OK, par contre pour écrire un document ex nihilo, DOMDocument n'est pas spécialement pratique ou du moins pas plus que XMLWriter. Je pense que DOMDocument laisse cette impression parce qu'il semble plus familier.

Citation:

Mais la vrai question c'est surtout pourquoi encore faire du XML en 2021 :mouarf:

Probablement parce qu'on a pas trouvé mieux. Alors oui JSON c'est plus léger, c'est moins verbeux, mais c'est tout. XML c'est bien plus qu'un format de données, c'est tout un écosystème qui permet de définir la grammaire d'un document, de garantir son intégrité, de l'interroger, de le transformer en n'importe quoi. Va faire ça avec du JSON.
Et puis plaisanterie mise à part, le XML est absolument partout.
10/09/2021, 10h20
grunk

Citation:

Envoyé par CosmoKnacki

Probablement parce qu'on a pas trouvé mieux. Alors oui JSON c'est plus léger, c'est moins verbeux, mais c'est tout. XML c'est bien plus qu'un format de données, c'est tout un écosystème qui permet de définir la grammaire d'un document, de garantir son intégrité, de l'interroger, de le transformer en n'importe quoi. Va faire ça avec du JSON.
Et puis plaisanterie mise à part, le XML est absolument partout.

Définir la grammaire en json : json-schema.org
Garantir l'intégrité : Résultat du parser + utilisation de linter , + validation du schema.
L'interroger : Si tu fais référence à XPath , si le langage ou la lib utilisé prend en charge JSON correctement c'est inutile puisque tu peux bien aller chercher n'importe quel partie du document comme bon te semble. Il existe évidemment des trucs comme jsonpath si on tient absolument à avoir une syntaxe de requêtage proche de xpath.
Le transformer : Si tu fais référence à XSLT , il existe des équivalence pour json mais effectivement pas de standard. C'est à peut près le seul intérêt que je pourrais trouver à xml.