J'ai ce code pour créer et mettre à jour le fichier xml :
<?php
$xmlFile = 'config.xml';
$xml = new SimpleXmlElement('<site/>');
$xml->title = 'Site Title';
$xml->title->addAttribute('lang', 'en');
$xml->saveXML($xmlFile);
?>
Cela génère le fichier xml suivant :
<?xml version="1.0"?>
<site>
<title lang="en">Site Title</title>
</site>
La question est : existe-t-il un moyen d'ajouter des CDATA avec cette méthode/technique pour créer le code xml ci-dessous ?
<?xml version="1.0"?>
<site>
<title lang="en"><![CDATA[Site Title]]></title>
</site>
2 votes
Il ne semble pas que SimpleXML supporte la création de nœuds CDATA. Essayez DOM au lieu de
2 votes
En quoi cela vous concerne-t-il ?
<title lang="en">Site Title</title>
y<title lang="en"><![CDATA[Site Title]]></title>
sont identiques, sauf que l'un d'eux utilise plus d'octets et est plus difficile à lire pour un humain.0 votes
@Quentin Bon point. C'est juste une exigence du client.
2 votes
@Quentin - L'utilisation de CDATA permet une écriture plus facile car vous n'avez pas à vous soucier d'échapper quoi que ce soit/de rendre le XML strict à l'intérieur des données. Par exemple, si vous écrivez
<title lang="en">Site<br>Title</title>
cela casserait l'analyseur XML (ouvrir une balise sans la fermer n'est pas du XML strict) alors que<title lang="en"><![CDATA[Site<br>Title]]></title>
ne le fait pas. Ainsi, lorsque vous traitez avec des clients, il est souvent plus Il est plus facile de lire un simple CDATA que tous les escamotages bizarres que ledit nœud non-CDATA peut devoir contenir pour éviter le CDATA.0 votes
@JimboJonny - Ce qui est bien si vous l'écrivez à la main, mais la question est de le générer à partir de PHP.
0 votes
@Quentin - Je ne suis pas d'accord. La nature littérale de CDATA rend encore plus utile le fait de ne pas avoir à échapper/utiliser la logique pour supprimer des choses qui casseraient le contenu XML créé dynamiquement. C'est l'équivalent de dire "Interprétez ceci comme une chaîne littérale, ne faisant pas partie du balisage XML" qui est extrêmement utile chaque fois que vous ne savez pas exactement quel contenu va se retrouver à l'intérieur d'un nœud, qu'il soit écrit à la main ou alimenté par un code, par exemple via un CMS. Il peut y avoir d'autres façons d'échapper des données pour que cela fonctionne lorsque la machine le fait, mais CDATA est une méthode tout aussi viable.
0 votes
@Quentin - Et les CDATA finissent souvent par être plus lisibles et par utiliser moins d'octets (le contraire de vos deux plaintes). Par exemple, qu'est-ce qui est le plus lisible : avoir des balises CDATA au début et à la fin ou un tas de contenu échappé partout ? Qu'est-ce qui consomme le plus d'octets de données : remplacer chaque caractère potentiellement offensant par des entités html ou avoir 12 octets de données supplémentaires au total ? Même un seul
<em></em>
échappée dans le contenu ajouterait autant d'octets que les balises CDATA qui l'entourent. Vous voyez, il y a de NOMBREUX cas où les CDATA sont une solution viable, qu'il s'agisse de XML généré manuellement ou par code.0 votes
"qu'il soit écrit à la main ou alimenté par du code, par exemple via un CMS" - S'il est alimenté par du code, comme c'est le cas dans la question, alors la bibliothèque se chargera de l'échappement ou de la conversion en CDATA. c'est à la bibliothèque de s'en préoccuper, pas à l'auteur.
0 votes
@Quentin - Il est tout à fait légitime pour l'auteur du CMS de décider qu'il souhaite que ses données soient stockées sous une forme à la fois plus lisible pour l'homme et, dans de nombreux cas, plus petite. CDATA est une forme XML légitime et même avantageuse et l'auteur d'un CMS a tout à fait le droit légitime de déterminer que c'est ainsi qu'il veut que ses données soient stockées, que ce soit ou non la sortie par défaut de SimpleXML. L'idée que personne ne devrait jamais faire autre chose que le comportement par défaut d'une classe/méthode parce que "c'est à la bibliothèque de s'en occuper" est manifestement absurde.