Parser un fichier XML avec SAXBuilder

Bonsoir,

J'ai suivi le tutoriel disponible sur le site
http://cynober.developpez.com/tutoriel/java/xml/jdom/

J'ai fait exactement comme dans le tuto, à savoir : parser le fichier avec SAXBuilder et initialiser la racine du document, à partir de là je fais le parcours de tout le document avec une méthode récursive en utilisant à chaque fois getChildren.

Après quelques lectures je m'aperçoit qu'il faudrait implémenter les méthodes de DefaultHandler pour pouvoir parler de technique push d'où l'utilisation d'un parseur SAX.

Je suis un peu confuse là. Alors pourquoi utiliser un parseur SAX si on utilise pas les détecteurs d'évenements. Dans le cas du tuto et donc mon travail inspiré du tuto on ne peut pas évidement pas parler de technique push?

Merci d'avance pour vos réponses.

Citation:

---

Envoyé par Sonya89

Après quelques lectures je m'aperçoit qu'il faudrait implémenter les méthodes de DefaultHandler pour pouvoir parler de technique push d'où l'utilisation d'un parseur SAX.

---

Tiens donc. Et sur la base de quoi t'es-tu "aperçue" de cela ?

Non, il n'y a aucune raison de faire ça si on utilise JDOM. Après, JDOM n'est pas la réponse à tous les besoins de parsing XML. Parfois une approche SAX est meilleure, mais bon... C'est surtout si le fichier est trop grand.

Ce que j'arrive pas à assimiler, c'est pourquoi on crée un document avec un constructeur basé sur SAX alors qu'on va utiliser DOM pour la manipulation des éléments. Je débute avec XML c'est pour ça que c'est un peu trop flou dans ma tête
Merci quand même pour votre réponse

Tu n'as pas besoin de l'assimiler. Que le constructeur soit basé sur SAX, Xerces, TNUOHD ou TRUC-MUCHE, n'est pas ton problème. Ce qui t'intéresse, c'est qu'il marche et qu'il fasse ce dont tu as besoin.

En l'occurrence, SAXBuilder est surtout par opposition à DOMBuilder. DOMBuilder prend une source DOM et la transforme en document JDOM. C'est un builder qui se base sur DOM, et qui le fait à ta place.

SAXBuilder prend quelque chose qui convient à SAX (genre, un fichier, un flux d'entrée socket, une String en mémoire, etc,) et la transforme en document JDOM. C'est un builder qui se base sur SAX, et qui le fait à ta place.

Ca évite de coder 50.000 parseurs :)

SAX est capable de Parser et génère des évènements à chaque fois qu'il rencontre un truc. C'est bien pour parser ou faire du XSL, par exemple ou du travail à la volée. Mais parfois on a besoin d'avoir tout un arbre de données plutot qu'un flux. Du coup, ben faut le créer cet arbre. Et quand tu le crée, qu'est-ce qui est le plus facile? Coder un nouveau parseur, avec mise en place de la validation et tout le reste? Ou réutiliser le parseur SAX qui, de toutes façons, est déjà inclu dans l'api de base de java? :mouarf: C'est le choix qu'on fait les auteurs de JDOM, réutiliser l'existant. SAXBuilder sert à parser les fichiers xml (stream, String, etc) et DOMBuilder sert à convertir un DOM en JDOM.

Citation:

---

Envoyé par tchize_

Ca évite de coder 50.000 parseurs :)

SAX est capable de Parser et génère des évènements à chaque fois qu'il rencontre un truc. C'est bien pour parser ou faire du XSL, par exemple ou du travail à la volée. Mais parfois on a besoin d'avoir tout un arbre de données plutot qu'un flux. Du coup, ben faut le créer cet arbre. Et quand tu le crée, qu'est-ce qui est le plus facile? Coder un nouveau parseur, avec mise en place de la validation et tout le reste? Ou réutiliser le parseur SAX qui, de toutes façons, est déjà inclu dans l'api de base de java? :mouarf: C'est le choix qu'on fait les auteurs de JDOM, réutiliser l'existant. SAXBuilder sert à parser les fichiers xml (stream, String, etc) et DOMBuilder sert à convertir un DOM en JDOM.

---

Merci énormément, je comprends mieux maintenant.

Citation:

---

Envoyé par thelvin

Tu n'as pas besoin de l'assimiler. Que le constructeur soit basé sur SAX, Xerces, TNUOHD ou TRUC-MUCHE, n'est pas ton problème. Ce qui t'intéresse, c'est qu'il marche et qu'il fasse ce dont tu as besoin.

.

---

Mon code marche impeccablement. Mais c'est bien de donner du sens à ce qu'on fait.

Bien pour ça que tchize_ et moi en avons donné le sens, à titre de culture générale -_-°.

Je reviens encore avec une question

j'ai vu sur un un autre tuto que "SAX ne permet de modifier ni de naviguer dans un document"

l'utilisation des handlers de début et de fin des éléments ne permettraient-ils pas la navigation? :?

Merci pour votre patience surtout

Ça rend possible la construction d'un arbre des éléments lus, et de prévoir un système de navigation dans cet arbre.

Mais ce n'est pas SAX qui le propose, si on veut ça en utilisant SAX, il faut le programmer soi-même. SAX indique juste des évènements du genre "et maintenant, il y a ouverture d'un nouvel élément <hello> avec les attributs ci-listés." Il ne dit absolument pas *où* se situe cet élément. Le seul moyen de le savoir est d'avoir enregistré tout ce qu'il y avait avant.

Citation:

---

Envoyé par thelvin

Ça rend possible la construction d'un arbre des éléments lus, et de prévoir un système de navigation dans cet arbre.

Mais ce n'est pas SAX qui le propose, si on veut ça en utilisant SAX, il faut le programmer soi-même. SAX indique juste des évènements du genre "et maintenant, il y a ouverture d'un nouvel élément <hello> avec les attributs ci-listés." Il ne dit absolument pas *où* se situe cet élément. Le seul moyen de le savoir est d'avoir enregistré tout ce qu'il y avait avant.

---

haa je comprends ^^ merci encore