Juste une petite question. J'ai un fichier xml. Par exmple :

Plus complexe bien sur.
J'ai besoin de garder ça en mémoire, et de bosser dessus.
Si je crée des bean "a", "1", et "aa" pour stocker les données contenues dans l'arbre, au lieu d'utiliser le modèle DOM précédement construit, ça vous choque ?
Genre un bean "a" qui à pour membre une Hashtable référençant les "1" qui lui appartiennent. les bean 1 ont aussi une Hashtable pour référencer les "aa", etc...
Vous pensez que je ferais mieux de ne rien réécrire, et d'utiliser plutôt la structure DOM générée automatiquement, plutôt que de la parcourir pour générer mes beans ?
 
Donnez votre avis svp, même brièvement. c'est important.
Merci.

JDom me semble plus simple et plus léger que DOM
Mais je me trompe peut-être (pour la légèreté).

Je parle pas d'écrire une autre API que DOM. Dsl, je m'exprime mal je crois.
en fait j'oppose de modèles :
1) utiliser la structure DOM obtenue par parsing pour générer des Bean de stockage.
2) conserver la structure DOM, et l'interprêter "à la volée", selon les besoin.
 
Est ce que vous privilègeriez une des 2 méthodes systèmatiquement ?
Est ce qu'une des 2 vous parait mauvaise, si oui, pourquoi ?

des objets, bordel, des objets!

 
Moi non plus.
JDom est une API Java qui construit une hiérarchie d'objets en mémoire, comme DOM, mais c'est plus facile à utiliser car les éléménts XML sont un peu plus typés (Element, Attribute, Text, CDATA, etc.) alors qu'avec DOM tu récupère très souvent des Node qui peuvent être n'importe quoi (aussi bien un Element qu'un noeud texte). C'est chiant, faut caster de partout.

Mais dans la solution 2, quand je parle de l'interpr^éter à la volée, ça utilise des objets aussi. Juste un converse le stockage dans l'arbre DOM, et les objets "aa", "1", .. servent juste à encapsuler l'arbre DOM.
(je précise que je soutient pas cette méthode. justement. je cherche des argument contre...)

 
Merci. Mais c'est pas la question que je me pose.

bah tu fais de la programmation orientée objet non?
bah voilà ton argument.
 
(client.getName() me parait plus net que clientDoc.getChild("name" ).getTextValue() nan? )

 
Faut pas être pour ou contre.
Simplement c'est pas optimal d'obtenir une arbo DOM pour la convertir
en une autre arbo d'objets !!!
Ca serait plus efficace de parser avec SAX si tu veux construire ta propre arbo.
 
C'est ce que j'ai du faire pour un projet d'editeur XML spécialisé

En fait je suis pas assez précis dnas mon expliquation.
Dans les 2 cas on à un objet "Client", avec une méthode getName.
Mais dans la méthode 1 on utilise un arbre DOM pour générer des objets qui reproduisent la structure de l'arbre (avec des Hashtable) en stockant les sous objets.
Dans la méthode 2 on généré les objets au besoin, en passant le noeud qui correspond au "client" (par exemple) au constructeur. Et la méthode client.getName() contiendra le code this.getChild("name" ).getTextValue()
 
Tu vois ce que je veux dire ?

bon ben alors les 2 methodes sentent des pieds

...2 avis opposés entre -- et Pascal ?

 
Et c quoi qui sent bon ?

du "vrai" objet, et passage à l'xml seulement en entrée et sortie, c-a-d quand t'as effectivement besoin d'xml

 
Ben la 1ère méthode c'est ça.
XML en entrée.
reproduction de la hérarchie dans des bean spécifiques.
Abandon du modèle DOM constuit.
 
 
XML généré si nécessaire.

 
Là je suis d'accord. XML doit être un format de sérialisation comme un autre pour une appli.

 
c pas ce que j'ai compris que tu disais...

 
Une fois que tu as analysé ton XML (avec DOM, SAX ou autre), tu travailles avec les objets , plus directement avec le XML.

ha, ton histoire d'hashtable m'a laissé pensé le contraire.
bah voilà

 
Mon histoire d'Hashtable, c'est pour reproduire les dépendances induite par le XML, dans mes bean.
Exemple :
<entreprise name="Microsoft">
  <employe name="Bill"/>
  <employe name="Roberto"/>
<entreprise>
 
Ben je vais avoir une classe Entreprise, qui à 2 attributs :
- une String : name
- une Hashtable : employe, dans laquelle la clé est un String (nom d'employé), et la valeur est un bean "Employe".
C'est logique ça, vous trouvez pas ?

ça peut se défendre oui  
mais il me semble qu'il faut penser dans le sens inverse: définir d'abord ton objet, ensuite l'xml..

sinon, employé, en anglais c'est employee avec 2 e

 
Tant mieux, tant mieux.  
Merci pour ces commentaires.

 
C'est parce que j'écrivais en franglais. dans cette langue, employe, c comme ça.