Discussion :

[Traroth2]

Bonjour,

Je viens de mettre en ligne une nouvelle petite API permettant de générer du XML avec Java.
L'idée est de générer du XML en utilisant une pile. On empile chaque niveau d'imbrication, et il suffit de dépiler pour redescendre d'un niveau. L'objectif étant d'obtenir de meilleurs performances qu'avec ce qui se fait actuellement, genre JDOM ou XStream. J'essayerais de faire un petit benchmark, à l'occasion.

Ca s'appelle Xpresso, c'est sous LGPL et vous pouvez le trouver ici si ça vous intéresse :

http://sourceforge.net/projects/xpresso/

Tout feedback m'intéresse, même mauvais...

[gronono]

Bonjour,

Je n'ai pas pu testé car ton code source n'est pas compatible avec java 1.5. Tu utilises les classe ArrayDeque et Deque (du package java.util) qui ne sont pas disponibles en 1.5 (ou alors il me manque quelque chose).

Sinon tu ne fais pas de TU ?

Et je n'ai pas compris comment tu arrives à un arbre à partir d'une pile.

Voila et bon courage.

Edit : Pourquoi les exceptions ne sont pas Runtime ?

[Traroth2]

Exact, j'utilise Deque, puisque c'est ce qui m'a semblé offrir les meilleurs performances. Comme beaucoup de gens se servent de Java 6 de nos jours, ça ne m'a semblé problématique. Visiblement si, donc il va au moins falloir que je le précise dans la présentation.
L'ensemble du code fait dans les 600 lignes, donc je n'ai pas écrit de tests unitaires pour l'instant. Mais tu as raison, c'est mal (il faudrait les écrire avant le code, toussa...)

Sinon, je n'ai pas généré la Javadoc pour l'instant. C'est idiot d'avoir mis en ligne sans ça, en fait. Peu de chances que grand monde s'en serve. Va falloir que je m'y mette ce soir.

Comment on arrive à un arbre à partir d'une pile. C'est un algorithme de parcours d'arbre avec priorité à la profondeur, en fait :
1 - Tu créés un document en spécifiant un élément racine, qui est empilé ou tu empiles un élément, qui devient donc ta profondeur courante dans l'arbre.
2 - Tu y ajoutes du contenu (un élément supplémentaire et donc retour à l'étape 1, ou un bloc CDATA, un élément vide, un commentaire ou une processing instruction)
3 -Tu dépiles un élément. S'il n'y a plus rien dans la pile, ton document est terminé, sinon, retour à l'étape 1 ou à l'étape 2

Si tu veux voir un exemple de fonctionnement, il doit y en avoir un dans la classe Document.

Je pense ajouter une notion de fragment à mon API, ce qui permettrait d'ajouter directement un bloc entier de XML à un endroit de l'arborescence. Ca permettrait d'assembler un XML à partir de morceaux...

Faire dériver les exceptions de RuntimeException, c'est une bonne idée. Je vais y penser.

Merci pour tes commentaires, en tout cas !

[Patriarch24]

J'ai vite fait un tour dans tes sources. Je pensais avoir à faire à une lib qui convertit un bean en xml, il n'en est rien.

Voici mes remarques (et questions) :

• Qu'est-ce que cela apporte par rapport à JAXP (en dehors des performances, ce que je n'ai pas testé) ?
• On peut utiliser une DTD, mais pas de schémas. Peut-on utiliser les namespaces ?
• Il n'y a pas de notion de pretty print.

Bon courage pour la suite.

[Traroth2]

Ce que ça apporte, c'est une approche que j'espère originale. Si c'est le cas, c'est déjà bien, je trouve. J'ai cherché d'autres briques logicielles qui procédaient de cette manière, et je n'ai rien trouvé. Des API qui transforment des beans en XML, il y en a déjà plusieurs, dont certaines font ça très bien (XStream), je ne vois pas l'intérêt qu'il y aurait à en créer une de plus...

C'est une API "bête", dans le sens où elle ne comprend pas le XML qu'elle génère. Il n'y rien dans le genre d'un arbre comme dans DOM ou d'un bean sous-jacent dont le XML reprendrait la structure, comme dans XStream, par exemple. Ces approches ne se caractérisent pas spécialement par leurs performances.
Ce qui veut dire que tu peux tout à fait inclure une référence à un XSD ou un namespace.

Par contre, aucune notion de pretty print, effectivement. C'est compact. Cela dit, une méthode permettant de renvoyer un pretty print du document, ça pourrait être intéressant, peut-être. Faut que j'y réfléchisse...

Le besoin qui m'a fait développer la première version de mon API, c'est un système qui permette de faire communiquer un serveur Java avec un client Flex, dans le cadre d'un projet de site grand public, donc avec une problématique de montée en charge très importante. Et là, les solutions existantes, y compris BlazeDS, ne tenaient tout simplement plus la route.

Merci pour tes commentaires.

[Traroth2]

Je viens de mettre une version 0.6 en ligne. Les exceptions dérivent maintenant de RuntimeException (merci à gronono pour la suggestion), on peut ajouter un Document dans un autre Document (il est enraciné à l'emplacement courant dans le Document destination. Les informations d'entête, type déclaration XML ou DTD, sont supprimées. Le Document ajouté doit également être fermé, de manière à éviter de se retrouver dans une situation inconsistente et de générer un XML mal formé). J'ai également terminé d'écrire et générer la Javadoc. Je me propose maintenant de permettre la duplication d'un Document en cours de traitement, ce qui pourrait être intéressant pour générer des XML au contenu proche.

Merci d'avance pour tout commentaire !

[Alain Defrance]

Si l'application ne supporte pas les schéma c'est un peu embattant pour utiliser des features avancées de XML. Il faudrait pouvoir générer un schéma puis des instances pour pouvoir les valider et de profiter de l'héritage/restriction et polymorphie.
A noter que pour la restriction ça risque d'être un peu hot vu que ça n'existe pas en OO je pense.
Ensuite pour faire des ns, on pourrait se baser sur les packages peut-être ?

[Traroth2]

Désolé, mais je n'ai pas saisi. Quelle fonctionnalité suggères-tu ?

[Alain Defrance]

Il faudrait pouvoir générer un schéma puis des instances pour pouvoir les valider et de profiter de l'héritage/restriction et polymorphie.

[Morbo]

Si ca ne gère pas les espaces de nom, schema, etc.
Pourquoi ne pas viser un générateur de texte balisé (qui couvre partiellement xml)?
Ce serait peut être plus raisonnable comme objectif. En tout cas c'est très enrichissant comme démarche, bon courage!

[Traroth2]

Merci pour tes encouragements. Je me faisais justement la même réflexion il y a quelques jours : pourquoi ne pas lui faire générer du JSON, du SGML ou de l'ASN.1 ? Il va falloir qu j'y réfléchisse...

Concernant la validation, c'est clairement hors du périmètre de ce que j'ai envie de faire faire à cette API. On y perdrait le principal avantage, la vitesse. Par contre, je commence à réfléchir à une surcouche qui permettrait de le faire en utilisant des bibliothèques existantes, ou qui permettrait de convertir le Document en arbre DOM, JDOM ou Dom4J, par exemple.

En attendant, je travaille sur une version 0.7 qui apportera beaucoup de modifs, notamment des versions thread-safe de Document et Element.

[Traroth2]

Finalement, je pense que je vais laisser tomber mon idée de module permettant la validation : JavaSE permet de faire ça sans le moindre problème. Le package javax.xml.validaton contient tout ce qu'il faut pour valider un document XML en fonction d'un XSD ou d'un Relax NG, et en cherchant un peu, on doit pouvoir trouver facilement pour une DTD aussi. Je ne vois pas l'intérêt de réinventer la roue.

[Traroth2]

Bonjour,

Je viens de mettre en ligne une version 0.7. Extrait du changelog :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
0.7 version, 2010-01-11
 
Bug fixes/optimizations/refactoring:
-Element.label is now final.
-In the Document.unstack() method: the peekFirst()+removeFirst() combination is replaced by pollFirst().
-Added a condition on open in the while loop in Document.finish() (useful in the inherited
 ConcurrentDocument class).
 
New features:
-A getStringReader() method is added to Document, returning the xml text as a StringReader.
-Document now implements Cloneable. Document.clone() overrides Object.clone().
 and returns a deep copy of the Document, including deep copies of all Element in the stack (see below).
-Element now implements Cloneable. Element.clone() overrides Object.clone() and returns a deep copy of
 the Element.
-Document now implements CharSequence and the length(), charAt(int), subSequence(int,int) and toString() methods
 are added.
-All classes now implement Serializable and contain a serialVersionUID.
-Comment, Element, ProcessingInstruction, Comment and CDATA constructors now protected. Instance are to be created 
 with methods from Document
-Added a thread-safe ConcurrentDocument class.
-Added a thread-safe ConcurrentElement class.
-Added a org.xpresso.xml.outputOutputter class, to output data in a Writer ou an OutputStream.

Et maintenant, avant que ça ne devienne trop complexe, je vais commencer à écrire des tests unitaires pour l'existant, de manière à procéder plus méthodiquement pour la suite. J'en profiterais pour écrire de la javadoc pour les packages. La prochaine version sera donc une 0.7.1.