Parser xml utilisé par PluXml ?

jojaba

Bonjour,

Ma question s'adresse aux développeurs et à ceux qui connaissent bien le noyau de PluXml et ne concerne pas ce magnifique outil, la réponse à cette question me permettra d'avancer dans un projet personnel basé également sur le stockage d'infos dans des fichiers xml...
J'ai pu constater que le moteur utilisé pour obtenir toutes les infos dans un .xml par PluXml est le moteur SAX. En revanche, je n'ai pas trouvé comment PluXml faisait pour modifier/supprimer des valeurs, des noeuds,... dans un tel fichier. Je suppose que DOM est utilisé. Vous confirmez ? D'autres mécanismes utilisés à propos de la gestion des fichiers xml ?
Merci d'avnace pour votre aimable information. Si pas de réponses, ce n'est pas grave, je saurais me débrouiller, je voulais juste être sûr d'utiliser les bons moyens pour utiliser de manière optimale un stockage dans des fichiers xml...

Stéphane

Bonjour

Le principe:

Lecture du fichier xml -> stockage des données dans un tableau -> manipulation des données à partir du tableau -> lecture du tableau pour reconstruire la chaîne de caractères avec les balises xml qui sera sauvegardée dans le fichier xml -> sauvegarde de la chaîne de caractères dans le fichier xml

Pas de manipulation du DOM donc.

jojaba

Merci Stéphane pour cette réponse.
J'en déduis qu'à aucun moment n'est ajouté un noeud supplémentaire. Tu recrées à chaque fois le contenu du fichier xml. C'est ça ? Pour les utilisateurs tu fais pareil ?
C'est ce qui est le plus rapide je suppose...

Stéphane

Oui c'est le meme principe pour tous les fichiers xml. Et c'est aussi le plus rapide vu le contexte.

flipflip

Je me permet d'intervenir surtout sur la partie gestion des nœuds il me semble qu'avec la méthode actuel il n'est pas possible de supprimer, pour la gestion des utilisateurs il y a un attribut delete qui est soit à 1 ou 0 suivant le cas du coups un utilisateur n'est pas réellement supprimé du fichier mais désactivé. Avec le temps le risque est de voir ce fichier augmenter en taille pour rien et d'avoir une baisse de perf.

Je ne sais pas si d'autres fichiers sont construit de la même manière ?

Philippe.

Stéphane

Si tu supprimes un utilisateur tu casses l'intégrité réferentielle pour te retrouver avec des articles sans auteur.
Et faut pas oublier que PluXml n'est pas un forum, ni outil collaboratif à grande échelle (donc normalement avec peu d'utilisateur). Le considérer telque serait une erreur et un mauvais choix fonctionnel.

Stéphane

Coté technique on peut tres bien supprimer des noeuds, puisqu'on recréer le flux xml à chaque enregistrement d'un fichier. Si on ne supprime pas complètement un utilisateur (attribut delete="1") c'est pour garantir l'historique des articles et de leurs auteurs. C'est un choix fonctionnel.

flipflip

Coté technique on peut tres bien supprimer des noeuds, puisqu'on recréer le flux xml à chaque enregistrement d'un fichier. Si on ne supprime pas complètement un utilisateur (attribut delete="1") c'est pour garantir l'historique des articles et de leurs auteurs. C'est un choix fonctionnel

Je n'avais pas penser à ce "petit" détail

jojaba

Stéphane a écrit:

Si tu supprimes un utilisateur tu casses l'intégrité réferentielle pour te retrouver avec des articles sans auteur.

Voilà un point auquel je n'avais pas pensé du tout. Merci flipflip et Stéphane pour avoir discuté de cela !!
Pour les curieux, voici comment est structuré le fichier xml permettant de stocker les utilisateurs (ici le cas d'un seul utilisateur) :

<user number="001" active="1" profil="0" delete="0"><!-- là on voit qu'on peut supprimer un utilisateur tout en le conservant dans l'arborescence, profil je ne vois pas trop à quoi ça correspond... -->
  <login><![CDATA[jojaba]]></login>
  <name><![CDATA[jojaba]]></name>
  <infos><![CDATA[]]></infos>
  <password><![CDATA[9351acde821d77874b9607a5a3a34add7f55a5ea]]></password>
  <salt><![CDATA[FDiukNL8Vt]]></salt><!-- là non plus je ne vois pas trop à quoi ça sert -->
  <email><![CDATA[]]></email>
  <lang><![CDATA[en]]></lang>
</user>

J'image que les CDATA sont surtout là pour des questions de sécurité..
Du coup, comme je risque d'avoir pas mal d'utilisateurs (pour l'instant, j'en ai 16), il va peut-être falloir que je révise mon projet... Ou est-ce que la solution xml reste valable (elle me plaisait bien car plus simple à mettre en place qu'une solution avec Base de données) ?

Stéphane

ça ne pose pas de problème de perfs 16 utilisateurs, meme pour le double ça doit etre négligeable

la valeur de l'attribut profil correspond à cela:

define('PROFIL_ADMIN', 0);
define('PROFIL_MANAGER', 1);
define('PROFIL_MODERATOR', 2);
define('PROFIL_EDITOR', 3);
define('PROFIL_WRITER', 4);

ces constantes sont définies dans le fichier config.php