Salut, dans le cadre d'un projet de fac, je dois utiliser xml pour créer un mini langage.
J'ai créé une dtd qui correspond a la grammaire de ce langage.
Bon, a partir de ca, je genere des classes java avec jbuilder sans probleme (une classe par element).
 
Mon prob, c'est que je dois instancier ces classes, ou une partie, en fonction d'un fichier xml (qui vérifie la dtd) et des elements et des attributs qu'il contient .
 
Je croisque je dois parcourir mon fichier xml et a chaque fois qu'il rencontre un element, il va instancier la classe correspondante et utiliser les valeurs des attributs dans ses méthodes .
Et je sais pas du tout comment faire ...
G regardé les tutos de jbuilder,et rapidement sur le site de sun, mais c pas trop ce que je recherche .
Si kk'un a compris mon charabiat, et avait une aide a me proposer (tuto, doc, ou procedure a faire) ce serai sympa
 
merci d'avance

bon en gros tu dois *parser* ton fichier xml, et chopper des valeurs dedans, que tu passeras au constructeur de tes classes?
 
si oui, la question que tu dois te poser, c'est: "comment lit-on un document xml", betement.
 
et laisse tomber jbuilder.

avec un titre pareil, je me demande s'il tente pas d'avoir une bonne place dans google quand même ...

lol, nan pas dans google, mais je voulais donner le plus d'elements dans le titre.
Alors, comment lire un document xml ?
Oui en effet, mais il faut que je recupere les infos pour le spasser aux constructeurs.
V faire un tour sur mon pote alors (google)
 
L'avantage de Jbuilder c que ca fait de beaux diagrammes (bah oue ca compte dans la notation) et puis je connais rien d'autre (sauf xemacs et vns, mais pour ce dernier c encore pire je crois )
 
G vu pa smal de personne parlées de l'api dom.
Est ce un element de soluce ??

jbuilder? diagrammes?
t'aurais un exemple à me montrer stp?
 
(ça fait ça à partir de tes sources?)
 
et pour lire l'xml bah DOMParser.getParser().parse(...)
en gros.

sinon t'as des libs comme jdom qui présentent une api bcp plus simple, et d'ailleurs plus performante. mais pas standard.
 
y'a aussi dom4j qui semble très apprécié, mais je suis pas certain d'ou il se situe par rapport aux standards et par rapport à jdom

Nan, g pas d'exemple sous la main la, g format mon dd y a pas lgts, et g plus mes vieux projets dans jbuilder (mon archive est sur un dd dans le placard).
Mais ca genere des diagrammes de classe pas trop moches oue
 
Sax me permet aussi de lire mon ficher xml si je ne m'abuse ?
 
Enfin, v creuser Jdom aussi, thx

sax aussi oui, mais à moins d'avoir un truc énorme à lire, dom te servira mieux.
 
pour jdom, méfie toi car ton prof s'attend pê à ce que tu utilises un parser standard
 
(hint: y'en a un par défaut dans la jdk>=1.4)

oki mci  

les dernières versions (8 ?) de jbuilder gèrent les diagrammes de classes UML ... je me demande si c'est pas un bout de rose qui a été intégré à jbuilder ...
 

   
pour le cas qu'il a donné, sax s'applique très très bien.  
 
 
 
Et j'ai jamais compris l'intérêt d'utiliser JDom par rapport à un parser DOM standard ... Si c'est pour les parfs, à la rigueur, (quoique je demande à être convaincu), mais pour la facilité d'utilisation, Dom + xpath c'est quand même très facilement manipulable ... Qu'est ce que ca apporte Jdom par rapport à ca ?

j'ai pas dit que sax n'irait pas, mais j'ai toujours cru que sax était plus complexe à utiliser et que ça n'apportait un avantage que sur de *gros* documents.
j'ai peut etre raté un épisode.
 

jdom est plus simple, si on se passe d'xpath. l'api est plus simple, moins de classes à manipuler, c'est plus intuitif (pas de trucs à faire du genre if nodeType==text || nodeType==je sais plus quoi..., t'as simplement getNodeTextContent() et getChildren ou qqchose dans le style)
 
et pour les perfs, j'ai jms pris la peine de tester, mais à l'époque je m'étais laissé entendre que sur de gros documents y'avait pas photo (ie que ça avait des perfs equivalentes à du sax)
 

Ca dépend pour quoi fair : le sax est beaucoup plus simple si l'utilisation que tu veux en faire se abse sur un modèle évenelentielle, c'est à daire que tu as pas ou peux de contexte à gérer au long du parsibng du document.  
Dans son cas, si c'est créer un objet avec les attributs du tag en paramêtres, c'est hyper simple.
 
Et l'avantage de sax sur les gros documents c'est simplement que ca ne t'éfondre pas la mémoire, contrairement à du DOM qui recréé en mémoire la structure objet correspondant à du XML => sur des gros documents, en général tu ne peux pas utiliser du DOM.
 

 
Ok ...  
 
Moi je fais du DOM avec une petite classe de méthodes utilitaires à côté ... J'ai l'avantage d'être standard et que ce soit facile à manipuler
 
 

Je peux imaginer que ce soit plus performant que du DOM classique (même si ca demande à être vérifier), mais de là à dire que ca a les perfs du sax c'est n'importe quoi ! Le cout d'un parsing sax est ridicule : pour résumer c'est juste lire le fichier et appeler des méthodes à chaque balise...
Dès qu'un parser recréé l'arbre XML en mémoire c'est forcément plus coûteux et surtout plus lourd en mémoire . D'un point de vue mémoire ca l'est surement moins pour JDom ...

> Moi je fais du DOM avec une petite classe de méthodes utilitaires à côté ... J'ai l'avantage d'être standard et que ce soit facile à manipuler  
 
ouais c'est ce qu'on fait ici aussi maintenant, même si je vois absolument pas ce que ça apporte d'être standard mais bon, soit
(meme avec jdom on avait des classes "utils" )
 
 
> Dès qu'un parser recréé l'arbre XML en mémoire c'est forcément plus coûteux et surtout plus lourd en mémoire  . D'un point de vue mémoire ca l'est surement moins pour JDom
 
ouais, je ne sais pas comment il fonctionne, mais pê que justement il ne crée pas la structure objet complement dès le parsing, mais uniquement au fur et à mesure des besoins. aucune idée..
 
tfaçons niveau parsing xml, maintenant si on veut etre branché on fait du xpp3

il me semlbe que digester est encore plus simple