SAX ou DOM ?

Bonjour à tous !

Je fais appel à vous pour un petit souci concernant du parsing XML avec la librairie standard, donc utilisation des API JAXP uniquement !

Je développe un logiciel qui peut s'apparenter à un agenda, dont je stocke les tâches dans un fichier XML.
Le lancement du logiciel doit déclencher le parsing du fichier XML, c'est-à-dire la création des objets métier manipulés par la suite à partir de ce fichier.
L'utilisateur ajoute, modifie et supprime des tâches tout au long de l'utilisation de l'application.
La fermeture du logiciel doit déclencher la sauvegarde de ces tâches dans le même fichier XML.

Ma question est donc la suivante :
Quelle méthode privilégier pour chacune des opérations de chargement et de sauvegarde ?
Mon dilemne est en fait que je ne sais pas si créer un document DOM au chargement et le garder en mémoire jusqu'à la sauvegarde est une bonne idée, ça utilise de la mémoire pendant toute l'utilisation de l'appli.
Pour l'instant je suis plus parti sur le fait de parser le fichier avec SAX et de créer un document DOM pour le modifier uniquement au moment de la sauvegarde.
D'un autre côté ça m'embête d'utiliser deux méthodes différentes, donc pourquoi pas SAX pour le chargement et la sauvegarde, mais ça me parait un peu complexe pour rien...

Je m'en remet donc à votre jugement !

Franchement si ton doc est bien trop gros n'utilise pas dom, tu va morfler sinon.

Sax c'est tres bien pour ca. En gros tu poura charger ton document xml à l'aide de SAXParser stocker les infos qui t'interesse dans une structure objet
puis à la fin de tes calculs tu sauvegarde le tout sans ne jamais utiliser dom

Ben justement à raison d'environ 100 caractères pour décrire les propriétés de l'agenda et en moyenne on va dire 600 caractères pour décrire une tâche, sachant que c'est un agenda destiné à des particuliers donc qui vont prévoir peut-être au maximum 500 tâches, ça nous fait 100 + 600 * 500 soit environ 300 000 octets...
Donc un fichier de 300 ko, à la limite voyon large et disons 500 ko mais je doute qu'il arrive jamais à cette taille...

Est-ce que 500 ko de XML génère un si gros document que ça en mémoire ?

Concrètement, quelle est la méthode la plus simple pour appliquer les modifications au XML (j'ai déjà expérimenté les deux pour la lecture, j'ai un petit faible pour SAX mais maintenant que je me suis familiarisé avec DOM c'est à peu près kif-kif) ?

Je ne saurais te dire comment faire, mis j'ai vu sur le forum il y a peu quelqu'un qui expliquait comment récupérer les données uniquement à un endroit précis du document xml pour ensuite les y enregistrer, tout ça avec SAX.
Je crois que c'était une histoire de buffer.

Peut-être que tu arriveras à retrouver le sujet en faisant une petite recherche.

Citation:

---

# SAX :
Simple API for XML travaille les documents XML de manière évenementielle.
C'est à dire que le parseur va lire (parcourir) le fichier ou flux XML et lever tout un ensemble d'événements lors de la rencontre avec un élément. Les éléments pouvant être des balises (ouvrantes ou fermantes), des portions de texte, des commentaires ou encore des instructions.
Cette API est particulièrement mise en avant pour sa rapidité de traitement. Par contre, son fonctionnement est peut-être un peu plus complexe à apréhender que celui de DOM.
Pour bien comprendre la structure et le fonctionnement de cette API regardez : Comment fonctionne l'API SAX ? .
# DOM :
Document Object Model, à la différence de SAX, ne va pas seulement parcourir le document XML, mais va, en plus, en fabriquer une représentation en mémoire.
Cette représentation est un arbre, que vous pourrez facilement parcourir (cf. org.w3c.dom.Document). Cet arbre représente l'organisation et le contenu du document XML. En contrepartie de sa facilité d'utilisation, DOM est plus gourmand en ressources et en temps.

---

il me semble que DOM est beaucoup plus simple d'utilisation ! :) mais plus lent :?

ça n'empêche pas de coder une couche supplémentaire à SAX pour simplifier le traitement pour un cas précis.
ça peut devenir encore plus simple qu'avec DOM.
Le tout étant de bien cerner SAX à la base.
Avec SAX tu peux faire tout ce que fait DOM, mais l'inverse n'est pas vrai.

Il faut juste identifier les besoins de chaque application utilisant XML.

Dans ce cas précis il n'y a pas besoin de garder en mémoire toutes les tâches de l'agenda, mais de pouvoir les retrouver et les sauvegarder facilement.


Dans une situation de base de données importantes, il m'est déjà arrivé d'utiliser XOM (donc le modèle DOM) mais avec plusieurs petits fichiers : un fichier "catalogue" contenait les informations générales sur des unités inférieures ainsi que la référence au fichier spécifique de chaque unité.

ces fichiers étaient tout simplement générés sur ce modèle :
0001.xml
0002.xml
...
FFFF.xml

Je n'accédais ainsi pas à toute ma base de données en même temps et je pouvait profiter de la simplicité de DOM. Et on peut aussi regrouper tout cela dans une archive zip avec une extension particulière à l'application.



Si tu veux tout mettre dans le même document XML, je conseille tout de même d'approfondir SAX (il faudra que je m'y mette moi aussi).